Elegant Temporal Label Switched Path Tunnel Service Controller

ABSTRACT

A method implemented by a network controller in a network, comprising receiving, by a temporal label switched path (T-LSP) manager of the network controller, a request for creating a temporal LSP in a scheduled time interval; computing, by a temporal path computation element (T-PCE) of the network controller, a shortest path in a network satisfying a constraint for the label switched path (LSP) in the scheduled time interval; reserving, in a temporal traffic engineering database (T-TED) of the network controller, resources on each link the LSP traverses for the scheduled time interval; and initiating, at a beginning of the scheduled time interval by the T-LSP manager, setup of the LSP in the network through sending a LSP creation request to a path computation client (PCC) on an ingress node of the LSP.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a divisional of co-pending U.S. patentapplication Ser. No. 15/187,384, filed Jun. 20, 2016 by Huaimo Chen, etal., and entitled “Elegant Temporal Label Switched Path Tunnel ServiceController,” which claims priority to U.S. Provisional PatentApplication 62/183,979 filed Jun. 24, 2015 by Huaimo Chen, et al., andentitled “Elegant Temporal Label Switched Path Tunnel ServiceController,” which are incorporated by reference.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

Software defined networking (SDN) is a networking paradigm thatdecouples network control and forwarding functions. The decoupling ofthe control plane from the data plane allows for centralization ofnetwork control, enabling effective policy administration and flexiblemanagement. The centralization of network control also facilitatesvarious network functionalities, such as network measurements, trafficengineering, enhanced quality of services, and enhanced access control.With the growing availability of SDN-enabled nodes and protocols, suchas OpenFlow, many organizations have started deploying SDN networks.

SUMMARY

In a SDN network, a SDN controller determines routes through the networkand configures each node in the network with routing instructions. In aSDN network that employs label switched paths (LSPs) for datatransportation, a SDN controller provides a solution for creating LSPsin the network without employing Resource Reservation Protocol (RSVP).Every LSP created by the SDN controller is up forever and networkresources are reserved for the LSP forever until the LSP is deleted.However, some LSPs may not be actively carrying traffic at all time.Thus, network resources may not be used efficiently. In addition, theLSPs created by a SDN controller are typically limited to the domaincontrolled by the SDN controller and may not tunnel through multipledomains. To resolve these and other problems, and as will be more fullyexplained below, a temporal tunnel service (TTS) controller is used tocreate temporal LSPs for carrying traffic at one or more particular timeintervals according to users' requests and reserve network resources forthe temporal LSPs in corresponding time intervals. In addition, the TTScontroller coordinates with other TTS controllers or path computationelement for temporal tunnel service (PCE-TTS) units to create temporalLSPs that tunnel through multiple domains.

In one embodiment, the disclosure includes a method implemented by anetwork element (NE) configured as a TTS controller, comprisingcomputing, via a processor of the NE, a path in a network for a temporalLSP, wherein the path satisfies a constraint in a scheduled timeinterval comprising a predetermined start time and a predetermined endtime, reserving, at a current time prior to the predetermined start timevia the processor, a first network resource on a link along the pathcomputed for the temporal LSP, wherein the first network resource isreserved for the temporal LSP to carry traffic in the scheduled timeinterval, and sending, at the predetermined start time via a transmitterof the NE, a LSP creation request to a node associated with the temporalLSP to request creation of the temporal LSP along the path in thenetwork. In some embodiments, the disclosure also includes sending, atthe predetermined end time via the transmitter, a LSP deletion requestto the node associated with the temporal LSP to request deletion of thetemporal LSP from the network, and/or further comprising receiving, viaa receiver of the NE, a creation request to create the temporal LSP inthe network for carrying the traffic in the scheduled time interval,wherein the creation request indicates the constraint, the predeterminedstart time, and the predetermined end time, and wherein the path iscomputed in response to the creation request, and/or wherein thecreation request further indicates that the scheduled time interval is arecurring time interval, wherein computing the path in the networkcomprises determining that the path satisfies the constraint in eachrecurring time interval, wherein reserving the first network resourcecomprises reserving the first network resource on the link for eachrecurring time interval, wherein sending the LSP creation requestcomprises sending the LSP creation request at a beginning of eachrecurring time interval, and wherein the method further comprisessending, at an end of each recurring time interval a LSP deletionrequest to the node to request deletion of the temporal LSP from thenetwork, and/or further comprising allocating, via the processor, aglobal identifier (ID) for identifying the temporal LSP in the network,and storing, in a memory of the NE, path information associated with thetemporal LSP, wherein the path information indicates the global ID, thefirst network resource, the scheduled time interval, a node sequence ofthe path, a status of the temporal LSP, or combinations thereof, and/orfurther comprising receiving, via a receiver of the NE, a deletionrequest to delete the temporal LSP from the network, sending, via thetransmitter, a LSP deletion request to the node requesting deletion ofthe temporal LSP from the network, receiving, via the receiver, a LSPdeletion response from the node indicating a deletion status of thetemporal LSP, releasing, via the processor, the first network resourcereserved on the link for the temporal LSP, releasing, via the processor,the global ID allocated for identifying the temporal LSP, and deleting,from the memory, the path information associated with the temporal LSP,and/or wherein the LSP creation request is sent via an interior gatewayprotocol (IGP), wherein the node is an egress node of the temporal LSP,and wherein the method further comprises receiving a LSP creationresponse from an ingress node of the temporal LSP indicating a creationstatus of the temporal LSP, and/or wherein the LSP creation request issent via a path computation element (PCE) communication protocol (PCEP),wherein the LSP creation request is a PCEP path computation LSP initiaterequest (PCInitiate) message, wherein the node is a path computationclient (PCC) associated with the temporal LSP, and wherein the methodfurther comprises receiving a PCEP LSP state report (PCRpt) message fromthe PCC indicating a creation status of the temporal LSP, and/or whereinthe network operates under a local domain, wherein the temporal LSPcrosses the local domain and a remote domain, wherein the path is afirst path portion of an end-to-end path of the temporal LSP, andwherein the method further comprises sending, via the transmitter, apath computation request to a remote network controller that controlsthe remote domain requesting computation of a second path portion in theremote domain that satisfies the constraint in the scheduled timeinterval for the end-to-end path of the temporal LSP, receiving, via areceiver of the NE, a path computation reply from the remote networkcontroller indicating the second path portion, sending, via thetransmitter, a resource reservation request to the remote networkcontroller requesting reservation of a second network resource in theremote domain for the temporal LSP in the scheduled time interval, andreceiving, via the receiver, a resource reservation reply from theremote network controller indicating a resource reservation status.

In another embodiment, the disclosure includes a network controllercomprising a processor configured to compute a path in a network for atemporal LSP, wherein the path satisfies a constraint in a scheduledtime interval comprising a predetermined start time and a predeterminedend time, and reserve, at a current time prior to the predeterminedstart time, a first network resource on a link along the path computedfor the temporal LSP, wherein the first network resource is reserved forthe temporal LSP to carry traffic in the scheduled time interval, and atransmitter coupled to the processor and configured to send, at thepredetermined start time, a LSP creation request to a node associatedwith the temporal LSP to request creation of the temporal LSP along thepath in the network, and send, at the predetermined end time, a LSPdeletion request to the node to request deletion of the temporal LSPfrom the network. In some embodiments, the disclosure also includes amemory coupled to the processor and configured to store a time-basedtraffic engineering database (TEDB) comprising resource informationassociated with the link by first time intervals, wherein the firstnetwork resource is reserved from the time-based TEDB, and/or whereinthe memory is further configured to store a time-based LSP database(LSPDB), and wherein the processor is further configured to allocate aglobal ID from the time-based LSPDB for identifying the temporal LSP inthe network, and store path information associated with the temporal LSPin the time-based LSPDB, wherein the path information indicates theglobal ID, the first network resource, the scheduled time interval, anode sequence of the path, a status of the temporal LSP, or combinationsthereof, and/or further comprising a receiver coupled to the processorand configured to receive a deletion request to delete the temporal LSPfrom the network, wherein the transmitter is further configured to senda LSP deletion request to the node requesting deletion of the temporalLSP from the network in response to the deletion request, and whereinthe processor is further configured to release the first networkresource reserved on the link for the temporal LSP to the time-basedTEDB, release the global ID allocated for identifying the temporal LSPto the time-based LSPDB, and deleting the path information associatedwith the temporal LSP from the time-based LSPDB, and/or wherein thenetwork operates under a local domain, wherein the temporal LSP crossesthe local domain and a remote domain, wherein the path comprises a firstpath portion of an end-to-end path of the temporal LSP, wherein thetransmitter is further configured to send a path computation request toa remote network controller associated with the remote domain requestingcomputation of a second path portion in the remote domain that satisfiesthe constraint in the scheduled time interval for the end-to-end path ofthe temporal LSP, and sending a resource reservation request to theremote network controller requesting reservation of a second networkresource in the remote domain for the temporal LSP in the scheduled timeinterval, and wherein the network controller further comprises areceiver coupled to the processor and configured to receive a pathcomputation reply from the remote network controller indicating thesecond path portion in response to the path computation request, andreceive a resource reservation reply from the remote network controllerindicating a resource reservation status in response to the resourcereservation request.

In yet another embodiment, the disclosure includes a method comprisingreceiving, by a temporal label switched path (T-LSP) manager of anetwork controller, a request for creating a temporal LSP in a scheduledtime interval, computing, by a temporal path computation element (T-PCE)of the network controller, a shortest path in a network satisfying aconstraint for the LSP in the scheduled time interval, reserving, in atemporal traffic engineering database (T-TED) of the network controller,resources on each link the LSP traverses for the scheduled timeinterval, and initiating, at a beginning of the scheduled time intervalby the T-LSP manager, setup of the LSP in the network through sending aLSP creation request to a PCC on an ingress node of the LSP. In someembodiments, the disclosure also includes sending, by the T-PCE, a PCEPopen message indicating that the T-PCE is capable of supporting temporalLSP path computation, temporal LSP initiation, and temporal LSPmaintenance, and/or wherein the temporal LSP crosses multiple domains inthe network, wherein the method further comprises communicating, by theT-PCE, with a remote T-PCE to get an end-to-end path for the LSPcrossing the multiple domains via a PCEP path computation request(PCReq) message, and wherein the PCReq message comprises a requestparameter (RP) object comprising an operation on time interval (OT)field indicating whether the PCReq message is a first request for pathcomputation in the scheduled time interval, a second request forbandwidth reservation for the scheduled time interval, or a thirdrequest for bandwidth release for the scheduled time interval, and aN-bit field indicating whether the temporal LSP is a point-to-point(P2P) LSP or a point-to-multipoint (P2MP) LSP, and/or wherein thescheduled time interval is a time period from a first time, denoted asTa, to a second time, denoted as Tb, wherein the PCReq message furthercomprises a time-interval object comprising a start-Time fieldindicating the first time that the LSP starts to carry traffic, and anend-Time field indicating the second time that the LSP ends carrying thetraffic, and wherein the first time and the second time are clock timesthat are synchronized among all NEs in the network, and/or wherein thescheduled time interval is a time period from a first time, denoted asTa, to a second time, denoted as Tb, and wherein the PCReq messagefurther comprises a time-interval object comprising a start-time-lengthfield indicating a start-time length in seconds from a current localclock time to the time Ta that the LSP starts to carry traffic, whereinthe start-time length is Ta minus the current local clock time, and anend-time-length field indicating an end-time length in seconds from thecurrent local clock time to the time Tb that the LSP ends carrying thetraffic, wherein the end-time length is Tb minus the current local clocktime, and/or wherein the scheduled time interval is a recurrent timeinterval that the LSP carries traffic, and wherein the PCReq messagefurther comprises a time interval object comprising a number-repeatsfield indicating a number of repeats, a repeat-time-length fieldindicating a repeat-time length in seconds of a repeat cycle for therecurrent time interval, and an options field indicating whether therecurrent time interval repeats every day, every week, every month,every year, or repeats every repeat-time length.

For the purpose of clarity, any one of the foregoing embodiments may becombined with any one or more of the other foregoing embodiments tocreate a new embodiment within the scope of the present disclosure

These and other features will be more clearly understood from thefollowing detailed description taken in conjunction with theaccompanying drawings and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following brief description, taken in connection with theaccompanying drawings and detailed description, wherein like referencenumerals represent like parts.

FIG. 1 is a schematic diagram of a SDN system.

FIG. 2 is a timing diagram of a time-agnostic link bandwidth profile.

FIG. 3 is a schematic diagram of a TTS system that implements temporalLSPs according to an embodiment of the disclosure.

FIG. 4 is a schematic diagram of a TTS system that implements temporalLSPs according to another embodiment of the disclosure.

FIG. 5 is a schematic diagram of a NE according to an embodiment of thedisclosure.

FIG. 6 is a timing diagram of a time-based link bandwidth reservationprofile according to an embodiment of the disclosure.

FIG. 7 is a protocol diagram of a method of creating a temporal LSPwithin a domain via an IGP according to an embodiment of the disclosure.

FIG. 8 is a protocol diagram of a method of deleting a temporal LSPwithin a domain via an IGP according to an embodiment of the disclosure.

FIG. 9 is a protocol diagram of a method of creating a temporal LSPwithin a domain via a PCEP according to an embodiment of the disclosure.

FIG. 10 is a protocol diagram of a method of deleting a temporal LSPwithin a domain via a PCEP according to an embodiment of the disclosure.

FIG. 11 is a protocol diagram of a method of creating a temporal LSPacross multiple domains according to an embodiment of the disclosure.

FIG. 12 is a protocol diagram of a method of deleting a temporal LSPthat tunnels through multiple domains according to an embodiment of thedisclosure.

FIG. 13 is a flowchart of a method of creating a temporal LSP accordingto an embodiment of the disclosure.

FIG. 14 is a flowchart of a method of creating a temporal LSP accordingto another embodiment of the disclosure.

FIG. 15 is a flowchart of a method of creating a temporal LSP accordingto another embodiment of the disclosure.

FIG. 16 is a flowchart of a method of deleting a temporal LSP accordingto an embodiment of the disclosure.

FIG. 17 is a flowchart of a method of creating a temporal LSP acrossmultiple domains according to an embodiment of the disclosure.

FIG. 18 is a flowchart of a method of deleting a temporal LSP thattunnels through multiple domains according to an embodiment of thedisclosure.

FIG. 19 is a schematic diagram illustrating a PCE capability flagssub-type-length-value (sub-TLV) according to an embodiment of thedisclosure.

FIG. 20 is a schematic diagram illustrating an open message extensiontype-length-value (TLV) according to an embodiment of the disclosure.

FIG. 21 is a schematic diagram illustrating a stateful PCE capabilityTLV according to an embodiment of the disclosure.

FIG. 22 is a schematic diagram illustrating a RP object according to anembodiment of the disclosure.

FIG. 23 is a schematic diagram illustrating a time-interval objectaccording to an embodiment of the disclosure.

FIG. 24 is a schematic diagram illustrating an absolute time intervalTLV according to an embodiment of the disclosure.

FIG. 25 is a schematic diagram illustrating a relative time interval TLVaccording to an embodiment of the disclosure.

FIG. 26 is a schematic diagram illustrating a combined time interval TLVaccording to an embodiment of the disclosure.

FIG. 27 is a schematic diagram illustrating a recurrent absolute timeinterval TLV according to an embodiment of the disclosure.

FIG. 28 is a schematic diagram illustrating a recurrent combined timeinterval TLV according to an embodiment of the disclosure.

FIG. 29 is a schematic diagram illustrating a recurrent relative timeinterval TLV according to an embodiment of the disclosure.

DETAILED DESCRIPTION

It should be understood at the outset that, although an illustrativeimplementation of one or more embodiments are provided below, thedisclosed systems and/or methods may be implemented using any number oftechniques, whether currently known or in existence. The disclosureshould in no way be limited to the illustrative implementations,drawings, and techniques illustrated below, including the exemplarydesigns and implementations illustrated and described herein, but may bemodified within the scope of the appended claims along with their fullscope of equivalent.

FIG. 1 is a schematic diagram of a software-defined network (SDN) system100. The SDN system 100 comprises an SDN controller 110 and a network130. The network 130 comprises a plurality of edge nodes 121, shown asPE1, PE2, PE3, and PE4, and a plurality of internal nodes 122, shown asP1, P2, P3, and P4, with some or all nodes interconnected by a pluralityof links 131. The edge nodes 121 are located at an edge or a boundary ofthe network 130. The internal nodes 122 are located within an area ofthe network 130. The underlying infrastructure of the network 130 may beany types of networks such as an electrical network, an optical network,or combinations thereof. The links 131 may comprise physical links suchas fiber optic links, electrical links, wireless links and/or logicallinks used to transport data in the network 130. The network 130operates under a single network administrative domain. The network 130may employ any forwarding data plane such as a multiprotocol labelswitching (MPLS) forwarding data plane. The SDN controller 110 iscommunicatively coupled to all edge nodes 121 and all internal nodes 122of the network 130. The system 100 decouples network control and networkforwarding functions.

The SDN controller 110 may be a virtual machine (VM), a hypervisor, orany other device configured to manage and control the network 130. TheSDN controller 110 obtains and/or maintains a full topology view of thenetwork 130. The SDN controller 110 computes forwarding paths throughthe network 130 according to the topology information. For example, theSDN controller 110 may employ a shortest path algorithm to determine apath between a source-destination pair in the network 130. Aftercomputing the paths, the SDN controller 110 sends forwardinginstructions to the edge nodes 121 and to the internal nodes 122 toinstruct the edge nodes 121 and the internal nodes 122 to forwardpackets according to the computed forwarding paths. The forwardinginstructions may be dependent on the routing protocol. The SDNcontroller 110 communicates with all edge nodes 121 and all internalnodes 122 via a plurality of communication channels 140. Thecommunication channels 140 are also referred to as controller-networkcommunication channels. In an embodiment, the communication channels 140are OpenFlow channels as described in the OpenFlow switch specificationversion 1.5.1 defined by Open Networking Foundation (ONF), Mar. 26,2015.

The edge nodes 121 and the internal nodes 122 are software programmablenetwork devices configured to perform forwarding functions in thenetwork 130 according to forwarding instructions received from the SDNcontroller 110 via the communication channels 140. The edge nodes 121are further configured to function as access points or interconnectionpoints between the network 130 and other networks, which may be similarto the network 130 or different from the network 130 and may operate inother domains. For example, the edge nodes 121 may establish networkingsessions and/or services with different networks, but may not exchangetopology information across the different networks.

In an embodiment, the network 130 may employ MPLS for data forwarding.In MPLS, data packets are assigned labels, which are referred to as pathlabels or segment labels, and the data packets are forwarded or directedon a LSP based on the labels. In such an embodiment, to establish a LSPbetween a source and a destination, the SDN controller 110 computes ashortest path through the network 130 for the LSP and reserves networkresources such as bandwidths on the links 131 along the computed path ofthe LSP. The network resources are reserved for the LSP forever or untilthe LSP is deleted. The SDN controller assigns path labels for the LSPand configures each edge node 121 and each internal node 122 along thepath of the LSP. As an example, a LSP 171 traversing the edge node PE1121, the internal nodes P1 and P2 122, and the edge node PE4 121 isestablished in the network 130. For example, the edge node PE1 121 isconnected to the source and the edge node PE4 121 is connected to thedestination. Thus, the edge node PE1 121 is referred to as an ingressnode of the LSP 171, the edge node PE4 121 is referred to as an egressnode of the LSP 171, and the internal nodes P1 and P2 122 are referredto as transit nodes of the LSP 171. Since the SDN controller 110 managesall network and label resources, the network 130 is not required toemploy any Resource Reservation Protocol (RSVP) or label distributionprotocol (LDP).

In a large-size SDN network, the management of all resources in thenetwork may be complex and the number of communication channels 140 maybe large. Thus, the design and implementation of the SDN controller 110may be complex and costly. In addition, all edge nodes 121 and allinternal nodes 122 in the network 130 are required to be upgraded toSDN-enabled nodes. For example, hardware-based network devices arerequired to be replaced with programmable or software programmablenetwork devices. Thus, the deployment of the system 100 may be timeconsuming and costly.

FIG. 2 is a timing diagram of a time-agnostic bandwidth reservationprofile 200. As used herein, time-agnostic means without any knowledgeof, or reference to, time. The x-axis represents time in some arbitraryconstant units. The y-axis represents unreserved bandwidth in somearbitrary constant units. The profile 200 represents the bandwidthreserved on a link 131 along the LSP 171. For example, the LSP 171 iscreated at a current time 210, denoted as T₀, and a bandwidth B0 isreserved on the link 131 for the LSP 171. As shown, the bandwidth B0 isreserved from the current time 210 to an indefinite end time or untilthe LSP 171 is deleted. However, the LSP 171 may only carry traffic oversome periods of time. Thus, the reserved bandwidth at the other time areidle or not being utilized. Therefore, the network resources in thesystem 100 may not be utilized efficiently.

Disclosed herein are various embodiments for creating a temporal LSP ina SDN network in one or more predetermined time intervals. The temporalLSP is scheduled to carry traffic in the predetermined time intervals.The disclosed embodiments employ a TTS controller to compute paths andreserve network resources by time intervals and allowing network nodesto establish temporal LSPs without awareness of the time intervals.Thus, the disclosed embodiments enable the deployment of temporal LSPtunnels with minimal impact to existing networks. The TTS controller mayinitiate creation and deletion of temporal LSPs by extending theinterior gateway protocol (IGP) or the PCEP. The TTS controllercommunicates with one or more nodes in the network depending on thenetwork communication protocol in use, but not all nodes as in the SDNsystem 100. In addition, the TTS controller may coordinate with otherTTS controllers to create and/or delete temporal LSP that crossesmultiple domains. Using LSPs for a predetermined time interval mayincrease network efficiency and scalability, reduce costs of operationand maintenance of networks, and provide new functions such as LSPtunnel service for a predetermined time interval and LSP tunnel servicescheduling.

FIG. 3 is a schematic diagram of a TTS system 300 that implementstemporal LSPs according to an embodiment of the disclosure. The system300 comprises a similar architecture as the hybrid model described inthe Internet Engineering Task Force (IETF) draft documentdraft-chen-teas-frmwk-tts-01.txt, Mar. 21, 2016, which is incorporatedherein by reference. The system 300 comprises a TTS controller 310communicatively coupled to a network 330. The network 330 comprises aplurality of edge nodes 321 shown as PE1, PE2, PE3, and PE4 and aplurality of internal nodes 322 shown as P1, P2, P3, and P4, some ofwhich may be interconnected by a plurality of links 331. The network 330operates under a single domain. The edge nodes 321 and the internalnodes 322 are similar to the edge nodes 121 and the internal nodes 122,respectively. The links 331 are similar to the links 131.

The TTS controller 310 may be a VM, a hypervisor, a computer servermachine, or any other device configured to creation and deletion oftemporal LSPs in the network 330 in predetermined or scheduled timeintervals. The TTS controller 310 manages and guarantees networkresources such as link bandwidths for the temporal LSPs in thepredetermined or scheduled time intervals. The TTS controller 310communicates with the edge nodes 321 and the internal nodes 322 toinitiate the creation and deletion of temporal LSPs in the network 330via one or more communication channels 340 similar to the communicationchannels 140. It should be noted that the TTS controller 310 maycommunicate with one or more of the edge nodes 321 and the internalnodes 322, but not all edge nodes 321 and all internal nodes 322. Anedge node 321 or an internal node 322 that is in communication with theTTS controller 310 is referred as a communication node.

The TTS controller 310 comprises a constrained shortest path first fortemporal tunnel service (CSPF-TTS) unit 311, a PCE-TTS unit 312, a LSPmanager 313, a protocol processing unit 314, a time-based TEDB 315, anda time-based LSPDB 316. The CSPF-TTS unit 311 is coupled to thetime-based TEDB 315. The PCE-TTS unit 312 is coupled to the time-basedTEDB 315 and other PCE-TTS units 362 of other domains. The LSP manager313 is coupled to the CSPF-TTS unit 311, the PCE-TTS unit 312, theprotocol processing unit 314, the time-based TEDB 315, and thetime-based LSPDB 316. Time-based refers to the management, maintenance,storage, and/or representation of information by time intervals. In anembodiment, the CSPF-TTS unit 311 is referred to as a temporal CSPF(T-CSPF), the PCE-TTS units 312 and 362 are referred to as T-PCEs, theLSP manager 313 is referred to as a T-LSP manager, the time-based TEDB315 is referred to as a T-TED, and the time-based LSPDB 316 is referredto as a temporal LSPDB (T-LSPDB).

The time-based TEDB 315 is configured to store traffic engineering (TE)information of the network 330 by time intervals. For example, thetime-based TEDB 315 indicates unreserved network resources in aplurality of time intervals. Some examples of network resourceinformation may include bandwidths, delays, data rates, link types,quality of service (QoS), statuses, and/or any other informationassociated with the links 331.

The CSPF-TTS unit 311 is configured to compute routing paths fortemporal LSPs in the network 330 satisfying certain constraints inpredetermined time intervals. The CSPF-TTS unit 311 may employ aconstrained shortest path first (CSPF) algorithm and consult with thetime-based TEDB 315 to compute the routing paths.

The PCE-TTS unit 312 is configured to coordinate with the CSPF-TTS unit311 and the other PCE-TTS units 362 to compute routing paths fortemporal LSPs crossing multiple domains in predetermined time intervals.The PCE-TTS units 362 are similar to the PCE-TTS unit 312. The PCE-TTSunit 312 communicates with the PCE-TTS units 362 via communicationchannels 350, which may implement the PCEP with extensions or anysuitable network communication protocol.

Although the CSPF-TTS unit 311 is illustrated as a separate componentfrom the PCE-TTS unit 312, the CSPF-TTS unit 311 may be integrated as aninternal component of the PCE-TTS unit 312. In addition, in someembodiments, the PCE-TTS unit 312 may be located external to the TTScontroller 310. It should be noted that the CSPF-TTS unit 311, thetime-based TEDB 315, and the PCE-TTS unit 312 may have access orknowledge of topology information within the domain of the network 330,but not other domains.

The time-based LSPDB 316 is configured to store global IDs foridentifying temporal LSPs in the network 330 and path informationassociated with temporal LSPs in the network 330. The time-based LSPDB316 stores and tracks availabilities of global IDs. The path informationmay include a global ID, a node sequences, time intervals, constraints,and states of each temporal LSP in the network 330. As an example, thenode sequence may be in the form of {PE4←P2←P1←PE1} to indicate that thetemporal LSP 371 traverses from the edge node PE1 321, followed by theinternal nodes P1 and P2 322, and to the edge node PE4 321. When anend-to-end path of a temporal LSP crosses multiple domains, thetime-based LSPDB 316 stores a global ID and path information of theportion of the end-to-end path that is within the network 330.

The protocol processing unit 314 is configured to communicate with oneor more edge nodes 321 and/or internal nodes 322 via one or morecommunication channels 340 as requested by the LSP manager 313 byextending the IGP, the border gateway protocol (BGP), the PCEP, theOpenFlow protocol, or any suitable network communication protocol. Whenemploying the IGP, the protocol processing unit 314 establishes acommunication channel with at least one node, which may be an edge node321 or an internal node 322. For example, the protocol processing unit314 establishes a communication channel 340 with the internal node P4322. When employing the PCEP, the protocol processing unit 314establishes communication channels with all edge nodes 321 of thenetwork 330. Since the protocol processing unit 314 is not required tocommunicate with all edge nodes 321 and all internal nodes 322 in thenetwork 330 as in the system 100, the design and management of resourcesin the system 300 is less complex and more efficient than the system100.

The LSP manager 313 is configured to manage and control creation anddeletion of temporal LSPs such as the temporal LSP 371 in the network330. Upon receiving a request to create a temporal LSP such as thetemporal LSP 371 in a number of time intervals, the LSP manager 313coordinates with the CSPF-TTS unit 311 and/or the PCE-TTS unit 312 toobtain a path satisfying the constraints of the temporal LSP in the timeintervals. The LSP manager 313 reserves a bandwidth on each link 331traversed by the temporal LSP from the time-based TEDB 315. The LSPmanager 313 allocates a global ID from the time-based LSPDB 316 foridentifying the temporal LSP and stores information of the temporal LSPin the time-based LSPDB 316. The LSP manager 313 coordinates with theprotocol processing unit 314 to initiate creation of the temporal LSP inthe network at the beginning of each time interval. After creating thetemporal LSP, the LSP manager 313 updates the status of the temporal LSPand notifies the user or application that the temporal LSP isestablished. At the end of each time interval, the LSP manager 313coordinates with the protocol processing unit 314 to initiate deletionof the temporal LSP.

Upon receiving a request to delete the temporal LSP or at the end of thelast time interval, the LSP manager 313 releases the reserved bandwidthto the time-based TEDB 315. The LSP manager 313 releases the reserved orallocated global ID to the time-based LSPDB 316 and removes informationabout the temporal LSP from the time-based LSPDB 316. The LSP manager313 coordinates with the protocol processing unit 314 to initiatedeletion of the temporal LSP in the network. The LSP manager 313 updatesthe status of the temporal LSP and notifies the user or application thatthe temporal LSP is deleted.

In an embodiment, when the system 300 employs the IGP, the protocolprocessing unit 314 sends LSP creation requests and LSP deletionrequests to an edge node 321 or an internal node 322 that is closest toan egress node of the temporal LSP and in communication with theprotocol processing unit 314 as described in the U.S. patent applicationSer. No. 14/737,142 filed on Jun. 11, 2015 by Huaimo Chen, et al., andtitled “Zone Routing System,” which is incorporated by reference. Insuch an embodiment, the edge nodes 321 and the internal nodes 322 arenot required to run RSVP-traffic engineering (RSVP-TE) or maintain softstates of the temporal LSP. The edge nodes 321 and the internal nodes322 along the path of the temporal LSP are not aware of any timeinterval. The edge nodes 321 and the internal nodes 322 along the pathof the temporal LSP exchange IGP messages to set up or tear downtemporal LSPs without considering any time interval, as described morefully below.

In another embodiment, when the system 300 employs the PCEP, theprotocol processing unit 314 sends LSP creation requests and LSPdeletion requests to an ingress node, which corresponds to an edge node321, of the temporal LSP. In such an embodiment, the edge nodes 321 andthe internal nodes 322 along the path of the temporal LSP employ RSVP-TEto reserve bandwidths on the links 331 traversed by the temporal LSP,but are not aware of any time interval. Since bandwidth is guaranteed bythe TTS controller 310, RSVP-TE bandwidth reservations on the edge nodes321 and the internal nodes 322 are always successful during theestablishment of the temporal LSP. Thus, temporal LSPs may be set up ortorn down in the network 330 without modifying the PCEP or the RSVP-TE.Therefore, the network 330 may be deployed to provide temporal LSPs withminimal impact. Although FIG. 3 describes the creation and deletion ofP2P temporal LSPs in a single domain, the LSP manager 313 may employsimilar mechanisms to create and delete P2MP LSPs and multi-domaintemporal LSPs, as described more fully below.

FIG. 4 is a schematic diagram of a TTS system 400 that implementstemporal LSPs according to another embodiment of the disclosure. The TTSsystem 400 is similar to the system 300 and illustrates a temporal LSP471 tunneling through multiple domains. The system 400 comprises aplurality of TTS controllers 410, each communicatively coupled to adomain 430 via one or more communication channels 440 similar to thechannels 340. The TTS controllers 410 are shown as TTS controller A andTTS controller B. The domains 430 are shown as domain A and domain B. Inone embodiment, each domain 430 corresponds to a network 330. In anotherembodiment, each domain 430 operates a different portion of a network330. Each domain 430 comprises a plurality of edge nodes 421 and aplurality of internal nodes 422 interconnected by links (not shown)similar to the links 131 and 331. The edge nodes 421 are similar to theedge nodes 121 and 321. The internal nodes 422 are similar to theinternal nodes 122 and 322. In the domain A 430, the edge nodes 421 areshown as PE1, PE2, PE3, and PE4 and the internal nodes 422 are shown asP1, P2, P3, and P4. In the domain B 430, the edge nodes 421 are shown asPE5, PE6, PE7, and PE8 and the internal nodes 422 are shown as P5, P6,P7, and P8. The domains 430 are interconnected by links (not shown)similar to the links 131 and 331. For example, the domains A and B 430are connected via a link between the edge node PE4 421 of the domain A430 and the edge node PE5 421 of the domain B 430.

The TTS controllers 410 are similar to the TTS controller 310. As shown,each TTS controller 410 comprises a PCE-TTS unit 412 similar to thePCE-TTS units 312 and 362 and may comprise other components such as theCSPF-TTS unit 311, the LSP manager 313, the time-based TEDB 315, and thetime-based LSPDB 316 (not shown). The TTS controllers 410 communicatewith each other via a communication channel 450 similar to thecommunication channel 350 between the PCE-TTS units 312 and 362 forcomputing an end-to-end path for a temporal LSP crossing multipledomains and reserving network resources along the path. Each TTScontroller 410 computes shortest paths and reserves bandwidths fortemporal LSPs within a domain 430 controlled by the TTS controller 410using similar mechanisms as described in the system 300 and as describedmore fully below. Similar to the system 300, the system 400 may employthe IGP, the BGP, the PCEP, the OpenFlow®, or any other networkcommunication protocol to create and delete temporal LSPs across thedomains 430, as described more fully below. As an example, the temporalLSP 471 tunnels across the domain A 430 and the domain B 430. Forexample, the TTS controller A 410 computes a shortest path for thetemporal LSP 471 in the domain A 430 in a number of time intervals andreserves bandwidth on links along the shortest path of the temporal LSPin the domain A 430. Similarly, the TTS controller B 410 computes ashortest path for the temporal LSP 471 in the domain B 430 in a numberof time intervals and reserves bandwidth on the links along the shortestpath of the temporal LSP 471 in the domain B 430.

FIG. 5 is a schematic diagram of a network element (NE) 500 according toan embodiment of the disclosure. For example, NE 500 may act as thenetwork controller 110, the TTS controllers 310 and 410, the edge nodes121, 321, and 421, the internal nodes 122, 322, and 422, and/or anyother network node in the systems 100, 300, or 400. NE 500 may beconfigured to implement and/or support the temporal LSP creation anddeletion mechanisms and schemes described herein. NE 500 may beimplemented in a single node or the functionality of NE 500 may beimplemented in a plurality of nodes. One skilled in the art willrecognize that the term NE encompasses a broad range of devices of whichNE 500 is merely an example. NE 500 is included for purposes of clarityof discussion, but is in no way meant to limit the application of thepresent disclosure to a particular NE embodiment or class of NEembodiments.

At least some of the features/methods described in the disclosure areimplemented in a network apparatus or component, such as an NE 500. Forinstance, the features/methods in the disclosure may be implementedusing hardware, firmware, and/or software installed to run on hardware.The NE 500 is any device that transports packets through a network,e.g., a switch, router, bridge, server, a client, etc. As shown in FIG.5, the NE 500 comprises transceivers (Tx/Rx) 510, which may betransmitters, receivers, or combinations thereof. The Tx/Rx 510 iscoupled to a plurality of ports 520 for transmitting and/or receivingframes from other nodes.

A processor 530 is coupled to each Tx/Rx 510 to process the framesand/or determine which nodes to send the frames to. The processor 530may comprise one or more multi-core processors and/or memory devices532, which may function as data stores, buffers, etc. The processor 530may be implemented as a general processor or may be part of one or moreapplication specific integrated circuits (ASICs) and/or digital signalprocessors (DSPs). The processor 530 comprises a temporal LSPcreation/deletion component 533, which may perform temporal LSP creationand deletion and may implement methods 700, 800, 900, 1000, 1100, 1200,1300, 1400, 1500, 1600, 1700, or 1800, as discussed more fully below,and/or any other flowcharts, schemes, and methods discussed herein. Assuch, the inclusion of the temporal LSP creation/deletion component 533and associated methods and systems provide improvements to thefunctionality of the NE 500. Further, the temporal LSP creation/deletioncomponent 533 effects a transformation of a particular article (e.g.,the network) to a different state. In an alternative embodiment, thetemporal LSP creation/deletion component 533 may be implemented asinstructions stored in the memory device 532, which may be executed bythe processor 530. Further, in the alternative embodiment, the NE 500may comprise any other means for implementing the methods 700, 800, 900,1000, 1100, 1200, 1300, 1400, 1500, 1600, 1700, or 1800.

The memory device 532 may comprise a cache for temporarily storingcontent, e.g., a random-access memory (RAM). Additionally, the memorydevice 532 may comprise a long-term storage for storing contentrelatively longer, e.g., a read-only memory (ROM). For instance, thecache and the long-term storage may include dynamic RAMs (DRAMs),solid-state drives (SSDs), hard disks, or combinations thereof. Thememory device 532 is configured to store databases (DBs) 534 such as thetime-based TEDB 315 and the time-based LSPDB 316 depending on theembodiments.

It is understood that by programming and/or loading executableinstructions onto the NE 500, at least one of the processor 530 and/ormemory device 532 are changed, transforming the NE 500 in part into aparticular machine or apparatus, e.g., a multi-core forwardingarchitecture, having the novel functionality taught by the presentdisclosure. It is fundamental to the electrical engineering and softwareengineering arts that functionality that can be implemented by loadingexecutable software into a computer can be converted to a hardwareimplementation by well-known design rules. Decisions betweenimplementing a concept in software versus hardware typically hinge onconsiderations of stability of the design and numbers of units to beproduced rather than any issues involved in translating from thesoftware domain to the hardware domain. Generally, a design that isstill subject to frequent change may be preferred to be implemented insoftware, because re-spinning a hardware implementation is moreexpensive than re-spinning a software design. Generally, a design thatis stable and that will be produced in large volume may be preferred tobe implemented in hardware, for example in an ASIC, because for largeproduction runs the hardware implementation may be less expensive thanthe software implementation. Often a design may be developed and testedin a software form and later transformed, by well-known design rules, toan equivalent hardware implementation in an ASIC that hardwires theinstructions of the software. In the same manner as a machine controlledby a new ASIC is a particular machine or apparatus, likewise a computerthat has been programmed and/or loaded with executable instructions(e.g., a computer program product stored in a non-transitorymedium/memory) may be viewed as a particular machine or apparatus.

FIG. 6 is a timing diagram of a time-based link bandwidth reservationprofile 600 according to an embodiment of the disclosure. The x-axisrepresents time in some arbitrary constant units. The y-axis representsunreserved bandwidth in some arbitrary constant units. The profile 600represents the bandwidth reserved on a link such as the links 331 alonga temporal LSP such as the temporal LSPs 371 or 471. For example, at acurrent time 610, denoted as T₀, a TTS controller such as the TTScontroller 310 or 410 reserves a bandwidth in an amount of B₀ for thetemporal LSP in a first time interval 621 and a second time interval622. The first time interval 621 begins at a time 611, denoted as T₁,and ends at a time 612, denoted as T₂. The second time interval 622begins at a time 613, denoted as T₃, and ends at a time 614, denoted asT₄. By reserving bandwidth or any other network resources for temporalLSPs by time intervals instead of indefinitely as shown the in theprofile 200, network resources may be utilized efficiently. It should benoted that the time intervals 621 and 622 may be indicated usingabsolute time, relative time, or combinations thereof. When employingabsolute time, T₀, T₁, T₂, T₃ and T₄ are represented by global clocktimes in a network such as the systems 300 or 400 synchronized among allnodes such as the edge nodes 121, 321, and 421 and the internal nodes122, 322, and 422 in the network. When employing relative time, eachnode may use a local clock time, which may be different from anothernode in the network. The details of indicating time intervals fortemporal LSP creation and deletion are described more fully below.

FIG. 7 is a protocol diagram of a method 700 of creating a temporal LSPsuch as the temporal LSPs 371 and 471 within a domain similar to thenetwork 330 or the domains 430 via the IGP according to an embodiment ofthe disclosure. The method 700 is implemented between a TTS controller,a first communication node of the network, an egress node PE4 of atemporal LSP, a transit node P1 of the temporal LSP, an ingress node PE1of the temporal LSP, and a second communication node of the network, anyof which may be implemented as the NE 500. The TTS controller is similarto the TTS controllers 310 or 410. The first and second communicationnodes are in direct association or communication with the TTS controllervia communication channels similar to the communication channels 340 or440. The method 700 is implemented when the TTS controller receives arequest to create a temporal LSP in a time interval, for example, from auser or an application.

At step 705, the TTS controller computes a shortest path for thetemporal LSP satisfying constraints of the temporal LSP in the timeinterval, for example using a CSPF-TTS such as the CSPF-TTS unit 311.The path traverses from the ingress node PE1 to the egress node PE4through the transit node P1 (e.g., {PE4←P1←PE1}). After computing thepath, the TTS controller reserves bandwidths on links such as the links131 and 331 along the path of the temporal LSP in the time interval, forexample, from a time-based TEDB such as the time-based TEDB 315. Afterreserving the bandwidths, the TTS controller allocates a global ID(e.g., LSP-ID) for the LSP, for example, from a time-based LSPDB such asthe time-based LSPDB 316.

At step 710, at a start time or beginning of the time interval, the TTScontroller determines that the first communication node is a next-hopnode or a closest node to the egress node PE4 among all communicationnodes and sends a first LSP creation request to the first communicationnode, for example, via a protocol processing unit such as the protocolprocessing unit 314. For example, the LSP creation request includes theLSP-ID, a node sequence along the path of the LSP, which may berepresented by {PE4←P1←PE1}, and a traffic class or source-destinationinformation associated with the temporal LSP.

At step 715, upon receiving the LSP creation request, the firstcommunication node determines that it is not the egress node PE4 andforwards the LSP creation request to the egress node PE4.

At step 720, upon receiving the first LSP creation request, the egressnode PE4 allocates a local label (e.g., L4), records the local labelunder the LSP-ID, and creates a forwarding information base (FIB) entry(e.g., (L4, pop)) to facilitate subsequent packet forwarding along thetemporal LSP. The FIB entry may be stored in local memory such as thememory device 532. For example, when the egress node PE4 receives apacket, the egress node PE4 determines a forwarding port according tothe FIB. When the received packet is attached with a label L4, theegress node PE4 removes the label L4 and forwards the packet to thedestination of the packet.

At step 725, the egress node PE4 sends a second LSP creation request tothe transit node P1 (e.g., a next upstream node along the path). Thesecond LSP creation request includes L4, LSP-ID, the traffic class,remaining hops in the path (e.g., {P1←PE1}), the LSP traffic class, andthe TTS controller address. The egress node PE4 may store the second LSPcreation request in the memory until the transit node P1 acknowledgesthe receipt of the second LSP creation request.

At step 730, upon receiving the second LSP creation request from theegress node PE4, the transit node P1 sends a first acknowledgement tothe egress node PE4 to acknowledge the receipt of the second LSPcreation request.

At step 735, upon receiving the first acknowledgement, the egress nodePE4 flushes the second LSP creation request from the memory.

At step 740, in response to the second LSP creation request, the transitnode P1 allocates a local label (e.g., L1), records label L1 underLSP-ID, and creates an FIB entry (e.g., (L1, L4)) to facilitatesubsequent packet forwarding to the egress node PE4. For example, whenthe transit node P1 receives a packet with a label L1, the transit nodeP1 removes the label L1, attaches a label L4 to the packet, and forwardsthe packet to the egress node PE4.

At step 745, the transit node P1 sends a third LSP creation request tothe ingress node PE1 (e.g., a next upstream node along the path). Thethird LSP creation request includes L1, LSP-ID, remaining hops in thepath (e.g., {PE1}), the LSP traffic class, and the TTS controlleraddress. Similarly, the transit node P1 may store the third LSP creationrequest in local memory until the ingress node PE1 acknowledges thereceipt of the third LSP creation request.

At step 750, upon receiving the third LSP creation request from thetransit node P1, the ingress node PE1 sends a second acknowledgement tothe transit node P1 to acknowledge the receipt of the third LSP creationrequest.

At step 755, upon receiving the second acknowledgement from the ingressnode PE1, the transit node P1 flushes the third LSP creation requestfrom the memory.

At step 760, in response to the third LSP creation request, the ingressnode PE1 creates an FIB entry (e.g., traffic class, push L1) tofacilitate subsequent packet forwarding to the transit node P1. Forexample, when the ingress node PE1 receives a packet corresponding tothe traffic class, the ingress node PE1 pushes or attaches the label L1to the packet and forwards the packet to the transit node P1.

At step 765, the ingress node PE1 determines that the secondcommunication node is a next-hop node to reach the TTS controller andsends a LSP creation response to the second communication node. The LSPcreation response may comprise the global ID and a LSP creation status.The second communication node may be the same as the first communicationnode or different from the first communication node.

At step 770, the second communication node forwards the LSP creationresponse to the TTS controller.

At step 775, upon receiving the LSP creation response, the TTScontroller updates a status of the temporal LSP and stores pathinformation of the temporal LSP in the time-based LSPDB. In addition,the TTS controller may notify the user or the application of thetemporal LSP creation status.

FIG. 8 is a protocol diagram of a method 800 of deleting a temporal LSPsuch as the temporal LSPs 371 or 471 within a domain similar to thenetwork 330 or the domains 430 via an IGP according to an embodiment ofthe disclosure. The method 800 is implemented between a TTS controller,a first communication node of the network, an egress node PE4 of a LSP,a transit node P1 of the LSP, an ingress node PE1 of the LSP, and asecond communication node of the network, any of which may beimplemented as the NE 500. The TTS controller is similar to the TTScontrollers 310 and 410. The first and second communication nodes are indirect communication or association with the TTS controller viacommunication channels similar to the communication channels 340. Themethod 800 is implemented after the TTS controller created a temporalLSP in a time interval by employing the method 700. The method 800 maybe implemented when the TTS controller receives a request from a user oran application to delete the temporal LSP or at the end of the timeinterval scheduled for the temporal LSP. For example, the temporal LSPis identified by a global ID (e.g., LSP-ID) and traverses from theingress node PE1 to the egress node PE4 through the transit node P1(e.g., {PE4←P1←PE1}). The egress node PE4 comprises an FIB entry, (L4,pop), for data forwarding along the LSP, where L4 is a local labelallocated by the egress node PE4 and recorded under LSP-ID. The transitnode P1 comprises an FIB entry, (L1, L4), for data forwarding along theLSP, where L1 is a local label allocated by the transit node P1 andrecorded under LSP-ID. The ingress node PE1 comprises an FIB entry,(traffic class, push L1), for data forwarding along the LSP. Each of theegress node PE4, the transit node P1, and the ingress node PE1 may storethe FIB entry, the global ID, and/or the local label in local memorysuch as the memory device 532.

At step 805, the first TTS controller searches for informationassociated with the temporal LSP from a first time-based LSPDB of thefirst TTS controller. The information indicates the egress node, thetransit nodes, and the ingress node of the temporal LSP.

At step 810, the TTS controller determines that the first communicationnode is a next-hop node or a closest node to the egress node PE4 amongall communication nodes and sends a first LSP deletion request to thefirst communication node. The first LSP deletion request includes theglobal LSP-ID, a node sequence, {PE4←P1←PE1}, for the LSP, and the TTScontroller address.

At step 815, upon receiving the first LSP deletion request, the firstcommunication node determines that it is not the egress node PE4 andforwards the first LSP deletion request to the egress node PE4.

At step 820, upon receiving the first LSP deletion request, the egressnode PE4 releases L4 recorded under LSP-ID and removes the FIB entry,(L4, pop).

At step 825, the egress node PE4 sends a second LSP deletion request tothe transit node P1 (e.g., a next upstream node along the LSP)requesting deletion of the LSP. The second LSP deletion request includesL4, LSP-ID, and the remaining hops in the LSP (e.g., {P1←PE1}). Theegress node PE4 may store the second LSP deletion request in the localmemory until the transit node P1 acknowledges the receipt of the secondrequest.

At step 830, upon receiving the second request from the egress node PE4,the transit node P1 sends a first acknowledgement to the egress node PE4to acknowledge the receipt of the second LSP deletion request.

At step 835, upon receiving the first acknowledgement from the transitnode P1, the egress node PE4 may flush the second LSP deletion requestfrom the local memory.

At step 840, in response to the second LSP deletion request, the transitnode P1 releases L1 recorded under LSP-ID and removes the FIB entry,(L1, L4).

At step 845, the transit node P1 sends a third LSP deletion request tothe ingress node PE1 (e.g., a next upstream node along the LSP)requesting deletion of the LSP. The third LSP deletion request includesL1, LSP-ID, and the remaining hop in the LSP (e.g., {PE1}). Similarly,the transit node P1 may store the third LSP deletion request in thelocal memory until the ingress node PE1 acknowledges the receipt of thethird LSP deletion request.

At step 850, upon receiving the third LSP deletion request from thetransit node P1, the ingress node PE1 sends a second acknowledgement tothe transit node P1 to acknowledge the receipt of the third request.

At step 855, upon receiving the second acknowledgement from the ingressnode PE1, the transit node P1 may flush the third LSP deletion requestfrom the local memory.

At step 860, in response to the third LSP deletion request, the ingressnode PE1 deletes the FIB entry, (traffic, push L1) corresponding to theLSP-ID.

At step 865, the ingress node PE1 determines that the secondcommunication node is a next-hop node to reach the TTS controller andsends a LSP deletion response to the TTS controller. The LSP deletionresponse includes the LSP-ID and a deletion status of the LSP.

At step 870, the second communication node forwards the LSP deletionresponse to the TTS controller.

At step 875, upon receiving the response, the TTS controller releasesthe reserved bandwidths to the time-based TEDB, releases the global IDto the time-based LSPDB, and removes path information of the temporalLSP from the time-based LSPDB. In addition, the TTS controller maynotify the user or the application of the temporal LSP deletion status.

Although the methods 700 and 800 are illustrated with a single transitnode, the methods 700 and 800 may be employed with any number of transitnodes, which each performs similar operations as the transit node P1. Inaddition, the methods 700 and 800 may be employed to create and delete aP2MP LSP, respectively. To create or delete a P2MP LSP, the TTScontroller sends a LSP creation or deletion request to each egress node(e.g., destination node) of the P2MP LSP.

Further, the methods 700 and 800 may be employed to create and deletetemporal LSPs scheduled for a series of scheduled time intervals,respectively. To create a temporal LSP scheduled for a number of timeintervals, the path is computed to satisfy the constraints of thetemporal LSP in each time interval and the bandwidths are reserved forthe temporal LSP in each time interval at step 705. At the beginning ofeach time interval, the TTS controller sends a LSP creation request tothe egress node PE4, which triggers the steps of 710-770. At the end ofeach time interval, the TTS controller sends a LSP deletion request tothe egress node PE4, which triggers the steps of 810-870. The step 875is performed at the end of the last time interval scheduled for thetemporal LSP.

It should be noted that the sending of the acknowledgements at steps730, 750, 830, and 850 and/or the flushing of the requests at steps 735,755, 835, and 855 may be optional. In addition, the first communicationnode and the second communication node may be the same node. Further,the first communication node may be the egress node or the ingress node.Similarly, the second communication node may be the egress node or theingress node.

The methods 700 and 800 may be applied when the first communication nodeor the second communication node are connected to the TTS controller viaone or more transit nodes. In one embodiment, each transit node along ashortest path between the TTS controller and first communication nodefunctions as a relay node. For example, when a relay node receives afirst LSP creation request from a previous-hop node along the shortestpath, which may be the TTS controller or another node, the relay nodegenerates a second LSP creation request according to the received firstLSP creation requests (e.g., same content). The relay node sends anacknowledgement to the previous-hop node to acknowledge the receipt ofthe first LSP creation request and sends the second LSP creation requestto a next-hop node along the shortest path. In such an embodiment, eachrelay node flushes a previously sent LSP creation request afterreceiving a corresponding acknowledgement. Similarly, when the TTScontroller receives an acknowledgement for a previously sent LSPcreation request, the TTS controller flushes the LSP creation request.In some other embodiments, relay nodes and communication nodes do notflush LSP creation requests after receiving acknowledgements fromnext-hop nodes. In such embodiments, the TTS controller flushes apreviously sent LSP creation request after receiving a corresponding LSPcreation response. The relay nodes and the communication nodes flush LSPcreation requests after previous-hop nodes flush the LSP creationrequests. The relay nodes perform similar operations for LSP creationresponse, LSP deletion request, and LSP deletion response.

FIG. 9 is a protocol diagram of a method 900 of creating a temporal LSPsuch as the temporal LSPs 371 or 471 within a domain similar to thenetwork 330 or the domains 430 via a PCEP according to an embodiment ofthe disclosure. The method 900 is implemented between a TTS controller(similar to the TTS controllers 310 or 410) and a path computationclient (PCC), any of which may be implemented as the NE 500. The PCC maybe implemented on an ingress node of the temporal LSP or a separate NEconfigured to signal creation or deletion of the temporal LSP along apath of the temporal LSP when instructed by the TTS controller. The TTScontroller is similar to the TTS controllers 310 or 410. The method 900is implemented when the TTS controller receives a request to create atemporal LSP in a time interval, for example, from a user, anapplication, an ingress node of the temporal LSP, or the PCC, forexample.

At step 910, the TTS controller computes a shortest path for thetemporal LSP satisfying constraints of the temporal LSP in the timeinterval, for example using a CSPF-TTS such as the CSPF-TTS unit 311.After computing the path, the TTS controller reserves bandwidths onlinks such as the links 131 or 331 along the path of the temporal LSP inthe time interval, for example, from a time-based TEDB such as thetime-based TEDB 315. After reserving the bandwidths, the TTS controllerallocates a global ID (e.g., LSP-ID) for the LSP, for example, from atime-based LSPDB such as the time-based LSPDB 316.

At step 920, at the beginning of the time interval, the TTS controllersends a LSP creation request to the PCC to initiate creation of thetemporal LSP in the domain. The LSP creation request indicates thecomputed path (e.g., a node sequence). The LSP creation request may besent via a PCInitiate message with extensions. The PCInitiate message isdescribed in the IETF draft document ietf-pce-pce-initiated-lsp-05.txt,Oct. 19, 2015.

At step 930, upon receiving the LSP creation request, the PCC triggersRSVP-TE to signal the temporal LSP along the path in the domain. Sincethe bandwidth is guaranteed by the TTS controller, RSVP-TE bandwidthreservation at each node along the path is successful.

At step 940, when the creation of the temporal LSP in the domain iscompleted, the PCC sends a LSP creation response to the TTS controller.The LSP creation response may be sent via a LSP state report (PCRpt)message with extensions. The PCRpt message is described in theietf-pce-pce-initiated-lsp-05.txt.

At step 950, upon receiving the LSP creation response, the TTScontroller updates status of the temporal LSP and stores pathinformation of the temporal LSP in the time-based LSPDB. In addition,the TTS controller may notify the user or the application of thetemporal LSP creation status.

FIG. 10 is a protocol diagram of a method 1000 of deleting a temporalLSP such as the temporal LSPs 371 or 471 within a domain similar to thenetwork 330 or the domains 430 via a PCEP according to an embodiment ofthe disclosure. The method 1000 is implemented between a TTS controllerand PCC of the domain, any of which may be implemented as the NE 500.The TTS controller is similar to the TTS controllers 310 or 410. Themethod 1000 is implemented after the TTS controller created a temporalLSP in a time interval, such as by employing the method 900. The method1000 may be implemented when the TTS controller receives a request froma user or an application to delete the temporal LSP or at the end of thetime interval scheduled for the temporal LSP. For example, the temporalLSP is identified by a global ID (e.g., LSP-ID).

At step 1010, the TTS controller searches for information associatedwith the temporal LSP from a time-based LSPDB such as the time-basedLSPDB 316 of the TTS controller. The information indicates the egressnode, the transit nodes, and the ingress node of the temporal LSP.

At step 1020, the TTS controller sends a LSP deletion request to the PCCto initiate deletion of the temporal LSP in the domain. The LSP deletionrequest indicates the path information of the temporal LSP.

At step 1030, upon receiving the LSP deletion request, the PCC triggersRSVP-TE to tear down the temporal LSP in the domain. At step 1040, aftercompleting the tear down, the PCC sends a LSP deletion response to theTTS controller. The LSP deletion response may be sent via a PCRptmessage to the TTS controller.

At step 1050, upon receiving the LSP deletion response, the TTScontroller releases the reserved bandwidths to the time-based TEDB,releases the global ID to the time-based LSPDB, and removes pathinformation of the temporal LSP from the time-based LSPDB. In addition,the TTS controller may notify the user or the application of thetemporal LSP deletion status.

Similar to the methods 700 and 800, the methods 900 and 1000 may beemployed to create and delete temporal LSPs in a series of timeintervals and to create and delete P2MP temporal LSPs.

FIG. 11 is a protocol diagram of a method 1100 of creating a temporalLSP such as the temporal LSPs 471 across multiple domains similar to thenetwork 330 or the domains 430 according to an embodiment of thedisclosure. The method 1100 is implemented, for example, between a firstTTS controller controlling a first domain, a second TTS controllercontrolling a second domain, and a third TTS controller controlling athird domain, any of which may be implemented as the NE 500. The first,second, and third network controllers are similar to the TTS controllers310 or 410. Each of the first, second, and third TTS controllersmaintains a time-based TEDB similar to the time-based TEDB 315 and atime-based LSPDB similar to the time-based LSPDB 316. The second domaininterconnects the first and third domains. The method 1100 isimplemented when the first TTS controller receives a request to create atemporal LSP that tunnels through multiple domains in a time interval,for example, from a user or an application. For example, a source of thetemporal LSP is connected to the first domain and a destination of thetemporal LSP is connected to the third domain. Thus, the end-to-end pathof the temporal LSP comprises a first path portion in the first domain,a second path portion in the second domain, and a third path portion inthe third domain.

At step 1110, the first TTS controller computes a shortest path for thetemporal LSP satisfying constraints of the temporal LSP in the timeinterval, for example, using a first PCE-TTS unit of the first TTScontroller such as the PCE-TTS units 312 or 412 to coordinate withPCE-TTS units of other domains.

At step 1120, the first TTS controller reserves bandwidths on links suchas the links 131 or 331 along the first path portion of the temporal LSPin the time interval from a first time-based TEDB of the first TTScontroller. The TTS controller allocates a first global ID (e.g.,LSP-ID) for identifying the temporal LSP in the first domain from afirst time-based LSPDB of the first TTS controller. The first TTScontroller stores information of the path computed into the LSPDB. Thefirst TTS controller may store the path information in the LSDPB usingvarious schemes. In one embodiment, the path comprises a first pathportion in the first domain, a first path key for a second path portionin the second domain, and a second path key for a third path portion inthe third domain in the LSPDB. In another embodiment, the path comprisesthe first path portion, the second path portion, and the third pathportion.

At step 1130, the first TTS controller sends a first request to thesecond TTS controller requesting the second TTS controller to reservebandwidths for the temporal LSP in the time interval, for example, viathe first PCE-TTS unit to a second PCE-TTS unit of the second TTScontroller. The first TTS controller may send the first request to thesecond TTS controller along the path of the temporal LSP. The firstrequest includes the first global ID and the first TTS controlleraddress and information associated with the remaining path from thefirst domain to the destination. The combination of the first global IDand the first TTS controller address uniquely identifies the LSPglobally in any TTS controller.

At step 1140, upon receiving the first request, the second TTScontroller reserves bandwidths on links along the second path portion ofthe temporal LSP in the time interval from a second time-based TEDB ofthe second TTS controller. The second TTS controller allocates a secondglobal ID for the temporal LSP from a second time-based LSPDB of thesecond TTS controller and stores the first global ID, the first TTScontroller address, and bandwidth reservation information into theLSPDB.

At step 1150, the second TTS controller determines that the destinationof the temporal LSP is not in the second domain according to the firstrequest and sends a second request to the third TTS controllerrequesting the third TTS controller to reserve bandwidths for thetemporal LSP. Similarly, the second controller may send the secondrequest to the third TTS controller along the path of the temporal LSP.The second request includes the first global ID, the first TTScontroller address, and information associated with the remaining pathfrom the second domain to the destination.

At step 1160, upon receiving the second request, the third TTScontroller reserves bandwidths on links along the third path portion ofthe temporal LSP in the time interval from a third time-based TEDB ofthe third TTS controller. The third TTS controller allocates a global IDfor the temporal LSP from a third time-based LSPDB of the third TTScontroller and stores the first global ID, the first TTS controlleraddress, and bandwidth reservation information into the LSPDB.

At step 1170, the third TTS controller determines that the destinationor the egress node of the temporal LSP is in the third domain and sendsa first reply to the second TTS controller indicating a firstreservation status of the temporal LSP in the third domain.

At step 1180, upon receiving the first reply, the second TTS controllersends a second reply to the first TTS controller indicating the firstreservation status and a second reservation status of the temporal LSPin the second domain. The first request, the second request, the firstreply, and the second reply may be sent via PCEP messages such as PCReqand path computation response (PCRep) messages with extensions, asdescribed more fully below. The PCReq and PCRep messages are describedin the IETF draft document draft-ietf-pce-stateful-pce-14.txt, Mar. 20,2016.

Subsequently, when the first, second, and third domains employ the IGP,the third TTS controller may employ similar mechanisms as described inthe methods 700 and 800 to initiate creation and deletion of thetemporal LSP at the beginning and the end of the time interval,respectively. For example, the third TTS controller sends a first LSPcreation request message to the egress node after it receives a requestfor reserving resources such as bandwidth for a link along the pathportion in the third domain or a second LSP creation request messagefrom the first TTS controller. The first LSP creation message comprisesthe first TTS controller address, the third path portion in the thirddomain, a first path key for the second path portion in the seconddomain, and a second path key for the first path portion in the firstdomain. The second LSP creation message comprises the first TTScontroller address, the first path key, and the second path key.

Upon receiving the first LSP creation request message, the egress nodeinitiates the creation of the LSP crossing the multiple domains alongthe end-to-end path of the LSP. The IGP creates the LSP in the thirddomain along the third path portion. When creating the LSP in the seconddomain, the IGP obtains information of the second path portion from thePCE-TTS in the second TTS controller using the first path key andcreates the LSP in the second domain along the second path portion. Whencreating the LSP in the first domain, the IGP obtains information of thefirst path portion from the PCE-TTS in the first TTS controller usingthe second path key and creates the LSP in the first domain along thefirst path portion. The ingress node of the LSP in the first domainsends the first TTS controller a LSP creation response indicating thestatus of the LSP creation. The first TTS controller updates the statusof the LSP in its LSPDB according to the response. Thus, the LSPcrossing multiple domains is created.

Alternatively, when the first, second, and third domains employ thePCEP, the first TTS controller may employ similar mechanisms asdescribed in the methods 900 and 1000 to initiate creation and deletionof the temporal LSP at the beginning and the end of the time interval.For example, the first TTS controller sends a PCInitiate message to aPCC on the ingress node. The PCInitiate message comprises the first pathportion in the first domain, a first path key for the second pathportion in the second domain, and a second path key for the third pathportion in the third domain. The PCC triggers the RSVP-TE to signal theLSP crossing the multiple domains along an end-to-end-path of the LSP.The RSVP-TE signals the LSP in the first domain along the first pathportion. When signaling the LSP in the second domain, the RSVP-TEobtains information of the second path portion from the PCE-TTS in thesecond TTS controller using the first path key and signals the LSP inthe second domain along the second path portion. When signaling the LSPin the third domain, the RSVP-TE obtains information of the third pathportion from the PCE-TTS in the third TTS controller using the secondpath key and signals the LSP in the third domain along the third pathportion. After signaling the LSP in three domains, the PCC sends thefirst TTS controller a PCRpt message indicating the status of the LSP.The first TTS controller updates the status of the LSP in its LSPDBaccording to the PCRpt message. Thus the LSP crossing multiple domainsis created.

In an alternative embodiment, the first TTS controller sends a requestto each of the second and third TTS controllers to request bandwidthreservation in each of the second and third domains instead of sending arequest to the next second TTS controller and having each TTS controllertrigger a request to a next TTS controller. It should be noted thatalthough the method 1100 is illustrated with three domains, the method1100 may be employed to create temporal LSPs across any number ofdomains.

FIG. 12 is a protocol diagram of a method 1200 of deleting a temporalLSP such as the temporal LSPs 471 that tunnels through multiple domainssimilar to the network 330 or the domains 430 according to an embodimentof the disclosure. The method 1200 is implemented between a first TTScontroller controlling a first domain, a second TTS controllercontrolling a second domain, and a third TTS controller controlling athird domain, any of which may be implemented as the NE 500. The first,second, and third network controllers are similar to the TTS controllers310 or 410. Each of the first, second, and third TTS controllersmaintains a time-based TEDB similar to the time-based TEDB 315 and atime-based LSPDB similar to the time-based LSPDB 316. The method 1200 isimplemented after a temporal LSP tunneling through the first, second,and third domain is created by using the method 1100. For example, anend-to-end path of the temporal LSP comprises a first path portion inthe first domain, a second path portion in the second domain, and athird path portion in the third domain. The method 1200 is implementedwhen the first TTS controller receives a request to delete the temporalLSP, for example, from a user or an application.

At step 1210, the first TTS controller searches for informationassociated with the temporal LSP from a first time-based LSPDB of thefirst TTS controller and initiates deletion of the temporal LSP in thefirst domain, for example, by performing steps 810-870 when employingthe IGP or performing steps 1010-1040 when employing a PCEP.

At step 1220, the first TTS controller sends a first request to thesecond TTS controller requesting the second TTS controller to releasethe bandwidths reserved for the temporal LSP, for example, via a firstPCE-TTS unit such as the PCE-TTS units 312, 362, or 412 of the first TTScontroller to a second PCE-TTS unit of the second TTS controller. Thefirst and second PCE-TTS units are similar to the PCE-TTS units 312 or412. The first TTS controller may send the first request to the secondTTS controller along the path of the temporal LSP. The first requestincludes information associated with the remaining path from the firstdomain to the destination.

At step 1230, upon receiving the first request, the second TTScontroller releases the bandwidths reserved for the temporal LSP to asecond time-based TEDB of the second TTS controller.

At step 1240, the second TTS controller determines that the destinationof the temporal LSP is not in the second domain according to the firstrequest and sends a second request to the third TTS controllerrequesting the third TTS controller to release the bandwidths reservedfor the temporal LSP. Similarly, the second controller may send thesecond request to the third TTS controller along the path of thetemporal LSP. The second request includes information associated withthe remaining path from the second domain to the destination.

At step 1250, upon receiving the second request, the third TTScontroller releases the bandwidths reserved for the temporal LSP to athird time-based TEDB of the third TTS controller.

At step 1260, the third TTS controller determines that the destinationof the temporal LSP is in the third domain and sends a first reply tothe second TTS controller indicating a first bandwidth release status ofthe temporal LSP in the third domain.

At step 1270, upon receiving the first reply, the second TTS controllersends a second reply to the first TTS controller indicating the firstbandwidth release status and a second bandwidth release status of thetemporal LSP in the second domain.

At step 1280, upon receiving the second reply, the first TTS controllerreleases the global ID reserved for the temporal LSP from the firsttime-based LSPDB and removes information associated with the temporalLSP from the first time-based LSPDB. In addition, the first TTScontroller may notify the user or the application of the LSP deletionstatus. It should be noted that the first request, the second request,the first reply, and the second reply may be sent via PCEP messages withextensions, as described more fully below.

In an alternative embodiment, the first TTS controller sends a requestto each of the second and third TTS controllers to request bandwidthrelease in each of the second and third domains instead of sending arequest to the next second TTS controller and having each TTS controllertrigger a request to a next TTS controller. It should be noted thatalthough the method 1200 is illustrated with three domains, the method1200 may be employed to delete temporal LSPs across any number ofdomains.

FIG. 13 is a flowchart of a method 1300 of creating a temporal LSP suchas the temporal LSPs 371 or 471 according to an embodiment of thedisclosure. The method 1300 is implemented by the TTS controller 310,which may be implemented as the NE 500. The method 1300 employs similartemporal LSP creation mechanisms as described in the system 300 and themethods 700 or 900. The method 1300 is implemented when the networkcontroller receives a request to create a temporal LSP. At step 1310, arequest to create a temporal LSP in the network for carrying traffic ina number of time intervals is received, for example, from a user or anapplication. The request may indicate constraints of the temporal LSP,timing information about the time interval, and/or traffic informationabout the traffic. The constraints may include bandwidth, latency,wavelengths, QoS, and/or number of hops. The timing information mayinclude a start time, an end time, a duration, and/or a repeat cycle, asdescribed more fully below.

At step 1315, a shortest path satisfying the constraints of the temporalLSP in each time interval is computed according to a time-based TEDBsuch as the time-based TEDB 315, for example, using a CSPF-TTS unit suchas the CSPF-TTS unit 311. The shortest path may be computed by employinga CSPF algorithm.

At step 1320, a network resource is reserved on each link along the pathin each time interval from the time-based TEDB, for example, using a LSPmanager such as the LSP manager 313. The reserved network resource maybe represented by a profile similar to the profile 600.

At step 1325, a global ID is allocated or reserved from a time-basedLSPDB such as the time-based LSPDB 316 for identifying the temporal LSPin the network, for example, using the LSP manager.

At step 1330, path information associated with the temporal LSP isstored in the time-based LSPDB.

At step 1335, a LSP creation request is sent to a node to initiatecreation of the temporal LSP in the network at the beginning of eachtime interval, for example, using a protocol processing unit such as theprotocol processing unit 314. When employing the IGP, the node is anegress node such as the edge node PE4 321 of the temporal LSP. Whenemploying the PCEP, the node is a PCC on an ingress node such as theedge node PE1 321 of the temporal LSP. At step 1340, a LSP creationresponse is received from the node. For example, the LSP creationresponse may indicate a status of the temporal LSP.

At step 1345, the status of the temporal LSP in the time-based LSPDB isupdated according to the received LSP creation response.

At step 1350, a LSP deletion request is sent to the node to initiatedeletion of the temporal LSP from the network at the end of each timeinterval.

At step 1355, the global ID is released to the time-based LSPDB at theend of the last time interval. At step 1360, the path information isremoved from the time-based LSPDB at the end of the last time interval.It should be noted that the method 1300 may be employed to create atemporal LSP with a single scheduled time interval or any number ofscheduled time intervals. In addition, the method 1300 may be employedto create a temporal LSP in a domain controlled by the networkcontroller when the temporal LSP is within a single domain or crossesmultiple domains, as described more fully below.

FIG. 14 is a flowchart of a method 1400 of creating a temporal LSP suchas the temporal LSPs 371 or 471 according to another embodiment of thedisclosure. The method 1400 is implemented by the TTS controller 310,which may be implemented as the NE 500. The method 1400 employs similartemporal LSP creation mechanisms as described in the system 300 and themethods 700, 900, or 1300. The method 1400 is implemented when thenetwork controller receives a request to create a temporal LSP. At step1410, a path is computed in a network for a temporal LSP, for example,using a CSPF-TTS unit such as the CSPF-TTS unit 311 according to atime-based TEDB such as the time-based TEBD 315. The path satisfies anetwork constraint in a time interval comprising a predetermined starttime and a predetermined end time. The constraint and the time intervalmay be indicated by the request. The constraint may include bandwidth,latency, and/or number of hops.

At step 1420, at a current time prior to the predetermined start, afirst network resource is reserved on a link along the path computed forthe temporal LSP, for example, using a LSP manager such as the LSPmanager 313 from the time-based TEDB. The first network resource isreserved for the temporal LSP to carry traffic in the time interval.

At step 1430, at the predetermined start time, a LSP creation request issent to a node associated with the temporal LSP to request creation ofthe temporal LSP along the path in the network. When employing the IGP,the node is an egress node such as the edge node PE4 321 of the temporalLSP. When employing the PCEP, the node is a PCC on an ingress node suchas the edge node PE1 321 of the temporal LSP.

FIG. 15 is a flowchart of a method 1500 of creating a temporal LSP suchas the temporal LSPs 371 or 471 according to another embodiment of thedisclosure. The method 1500 is implemented by the TTS controller 310,which may be implemented as the NE 500. The method 1500 employs similartemporal LSP creation mechanisms as described in the system 300 and themethods 700, 900, 1300, or 1400. The method 1500 is implemented when thenetwork controller receives a request to create a temporal LSP. At step1510, a request for creating a temporal LSP in a time interval isreceived by a T-LSP manager such as the LSP manager 313 of the networkcontroller. The request may indicate constraints of the temporal LSP,timing information about the time interval, and/or traffic informationabout the traffic. The constraints may include bandwidth, latency,wavelengths, QoS, and/or number of hops. The timing information mayinclude a start time, an end time, a duration, and/or a repeat cycle, asdescribed more fully below.

At step 1520, a shortest path in a network satisfying a constraint forthe LSP in the time interval is computed by a T-PCE such as the PCE-TTSunit 312 of the network controller.

At step 1530, resources are reserved in a T-TED such as the time-basedTEDB 315 of the network controller on each of link the LSP traverses forthe time interval.

At step 1540, at a beginning of the time interval, setup of the LSP isinitiated in the network through sending a LSP creation request to a PCCon an ingress node of the LSP by the T-LSP manager.

FIG. 16 is a flowchart of a method 1600 of deleting a temporal LSP suchas the temporal LSPs 371 or 471 according to an embodiment of thedisclosure. The method 1600 is implemented by the TTS controller 310,which may be implemented as the NE 500. The method 1600 employs similartemporal LSP deletion mechanisms as described in the system 300 and themethods 800 or 1000. The method 1600 is implemented after a temporal LSPis created for carrying traffic in a time interval, for example, byemploying the methods 700, 800, 1300, 1400, or 1500. Network resourcessuch as link bandwidths are reserved from a time-based TEDB such as thetime-based TEDB 315 for the temporal to carry traffic LSP in one or moretime intervals. A global ID is allocated from a time-based LSPDB such asthe time-based LSPDB 316 for identifying the temporal LSP in the networkand path information associated with the temporal LSP is stored in thetime-based LSPDB.

At step 1610, a request to delete the temporal LSP from the network isreceived, for example, from a user or an application of the temporalLSP.

At step 1620, the path information of the temporal LSP is obtained, forexample, by searching time-based LSPDB.

At step 1630, a LSP deletion request is sent to a node to initiatedeletion of the temporal LSP from the network, for example, using aprotocol processing unit such as the protocol processing unit 314. Whenemploying the IGP, the node is an egress node such as the edge node PE4321 of the temporal LSP. When employing the PCEP, the node is a PCC onan ingress node such as the edge node PE1 321 of the temporal LSP.

At step 1640, a LSP deletion response is received from the node, forexample, indicating a status of the temporal LSP.

At step 1650, the network resource reserved for the temporal LSP inremaining time intervals is released to the time-based TEDB.

At step 1660, the global ID allocated for identifying the temporal LSPis released to the time-based LSPDB.

At step 1670, the path information associated with the temporal LSP isdeleted from the time-based LSPDB. It should be noted that the method1600 may be employed to delete a temporal LSP with a single scheduledtime interval or any number of scheduled time intervals. In addition,the method 1600 may be employed to delete a temporal LSP in a domaincontrolled by the network controller when the temporal LSP is within asingle domain or crosses multiple domains, as described more fullybelow.

FIG. 17 is a flowchart of a method 1700 of creating a temporal LSP suchas the temporal LSP 471 across multiple domains according to anembodiment of the disclosure. The method 1700 is implemented by the TTScontroller 310, which may be implemented as the NE 500. The method 1700employs similar temporal LSP creation mechanisms as described in thesystem 300 and the methods 700, 900, 1100, 1300, 1400, or 1500. Themethod 1700 is implemented when the network controller receives arequest to create a temporal LSP. At step 1710, a request to create atemporal LSP that crosses a local domain and a remote domain forcarrying traffic in a number of time intervals is received, for example,from a user or an application. The local domain is controlled by thenetwork controller. The remote domain is controlled by a remote networkcontroller similar to the TTS controller 310. The request may indicateconstraints of the temporal LSP, timing information about the timeinterval, and/or traffic information about the traffic. The constraintsmay include bandwidth, latency, wavelengths, QoS, and/or number of hops.The timing information may include a start time, an end time, aduration, and/or a repeat cycle, as describe more fully below. At step1715, a global ID is allocated for the temporal LSP, for example, from atime-based LSPDB such as the time-based LSPDB 316. The information suchas the constraints and the timing associated with the temporal LSP isstored in the time-based LSPDB 316.

At step 1720, a first path portion in the local domain satisfying theconstraints of the temporal LSP in the time interval for an end-to-endpath of the temporal LSP is computed, for example, using a PCE-TTS unitsuch as the PCE-TTS unit 312.

At step 1730, a path computation request is sent to the remote networkcontroller that controls the remote domain. The path computation requestrequests computation of a second path portion in the remote domain thatsatisfies the constraint in the time interval for the end-to-end path ofthe temporal LSP. For example, the path computation request is sent bythe PCE-TTS unit of the network controller to a remote PCE-TTS unit ofthe remote network controller.

At step 1740, a path computation reply is received from the remotenetwork controller indicating a path computation status.

At step 1750, a network resource is reserved on each link along thefirst path portion in each time interval.

At step 1760, a resource reservation request is sent to the remotenetwork controller requesting reservation of a second network resourcein the remote domain for the temporal LSP in the time interval. Forexample, the resource reservation request is sent by the PCE-TTS unit ofthe network controller to the remote PCE-TTS unit of the remote networkcontroller.

At step 1770, a resource reservation reply is received from the remotenetwork controller indicating a resource reservation status in theremote domain for the temporal LSP.

At step 1790, path information associated with the temporal LSP isstored in the time-based LSPDB 316.

At step 1795, a LSP creation request is sent to a node to initiatecreation of the temporal LSP in the network at the beginning of eachtime interval. When employing the IGP, the node is an egress node suchas the edge node PE4 321 of the temporal LSP. When employing the PCEP,the node is a PCC on an ingress node such as the edge node PE1 321 ofthe temporal LSP. Subsequently, the network controller may notify theuser or the application that the temporal LSP is created in the network.It should be noted that the method 1700 may be implemented in the orderas shown or alternatively configured as determined by a person ofordinary skill in the art to achieve similar functionalities.

FIG. 18 is a flowchart of a method 1800 of deleting a temporal LSP suchas the temporal LSP 471 that tunnels through multiple domains accordingto an embodiment of the disclosure. The method 1800 is implemented bythe TTS controller 310, which may be implemented as the NE 500. Themethod 1800 employs similar temporal LSP deletion mechanisms asdescribed in the system 300 and the methods 800, 1000, 1200, or 1600.The method 1800 is implemented after a temporal LSP crossing multipledomains is created by employing the methods 700, 800, 1100, 1300, 1400,1500, or 1700. For example, the temporal LSP traverses through a localdomain controlled by the network controller and an interconnectingremote domain controlled by a remote network controller. The networkcontroller reserved a resource such as link bandwidths from a time-basedTEDB such as the time-based TEDB 315 for the temporal path to carrytraffic of the LSP in one or more time intervals within the localdomain. The network controller requested the remote network controllerto reserve a resource in the remote domain for carrying the traffic ofthe LSP. The network controller allocated a global ID from a time-basedLSPDB such as the time-based LSPDB 316 for the temporal LSP and storedpath information of the temporal LSP in the time-based LSPDB.

At step 1810, a request is received to delete a temporal LSP thatcrosses the local domain and the remote domain for carrying traffic inthe time interval, for example, from a user or an application of thetemporal LSP.

At step 1820, deletion of the temporal LSP is initiated, for example, byemploying similar mechanisms as the method 800, 1000, or 1600. A LSPdeletion request is sent to a node to initiate deletion of the temporalLSP from the network, for example, using a protocol processing unit suchas the protocol processing unit 314. When employing the IGP, the node isan egress node such as the edge node PE4 321 of the temporal LSP. Whenemploying the PCEP, the node is a PCC on an ingress node such as theedge node PE1 321 of the temporal LSP.

At step 1830, a resource release request is sent to the remote networkcontroller requesting release of the second network resource in theremote domain, for example, using a PCE-TTS unit such as the PCE-TTSunit 312 of the network controller to a remote PCE-TTS unit of theremote network controller.

At step 1840, a resource release reply is received from the remotenetwork controller indicating a deletion status of the temporal LSP inthe remote domain.

At step 1850, the global ID is released to the time-based LSPDB.

At step 1860, the path information associated with the temporal LSP isremoved from the time-based LSPDB. Subsequently, the network controllermay notify the user or the application that the temporal LSP is deletedfrom the network. It should be noted that the method 1800 may beimplemented in the order as shown or alternatively configured asdetermined by a person of ordinary skill in the art to achieve similarfunctionalities.

FIGS. 19-22 illustrate various embodiments of extensions to the IGP andthe PCEP for facilitating creation and deletion of temporal LSPs such asthe temporal LSPs 371 or 471. FIG. 19 is a schematic diagramillustrating a PCE capability flags sub-TLV 1900 according to anembodiment of the disclosure. The sub-TLV 1900 is employed by a PCE suchas the PCE-TTS unit 312, 362, or 412 to advertise the PCE's pathcomputation capabilities when employing the IGP. The sub-TLV 1900 is anextension to the PCE-CAP-FLAGS sub-TLV described in the IETF draftdocument Request For Comment (RFC) 5088. For example, the PCE-TTS unitsends a link state advertisement (LSA) comprising the sub-TLV 1900during PCE discovery using open shortest path first (OSPF). The sub-TLV1900 comprises a type field 1910, a length field 1920, and a PCEcapability flags field 1930. The type field 1910 is about two octetslong and is set to a value of five to indicate that the sub-TLV 1900 isa PCE-CAP-FLAGS sub-TLV. The length field 1920 is about two octets longand indicates a length of the PCE capability flags field 1930. Forexample, the length field 1920 indicates the length of the PCEcapability flags 1930 in multiple of about four octets. The PCEcapability flags field 1930 comprises a T flag 1931, an M flag 1932, anda P flag 1933. The T flag 1931 is about one bit long and indicateswhether the PCE supports initiation of a temporal LSP for a given timeinterval. The M flag 1932 is about one bit long and indicates whetherthe PCE supports path computation for a temporal P2MP LSP in a giventime interval. The P flag 1933 is about one bit long and indicateswhether the PCE supports path computation for a temporal P2P LSP in agiven time interval. The PCE capability flags field 1930 may compriseother flags as described in RFC 5088.

FIG. 20 is a schematic diagram illustrating an open message extensionTLV 2000 according to an embodiment of the disclosure. The TLV 2000 isemployed by a PCE such as the PCE-TTS unit 312, 362, or 412 to exchangepath computation capability information with other PCEs when employingthe PCEP. For example, the PCE sends a PCEP open message comprising theTLV 2000 to another PCE during a PCEP session establishment, where thePCEP open message is described in the IETF draft document RFC 5440. TheTLV 2000 comprises a type field 2010, a length field 2020, and acapability flags field 2030. The type field 2010 is about two octetslong and is set to a value of eight to indicate that the TLV 2000 is anopen message extension TLV. The length field 2020 is about two octetslong and indicates a length of the capability flags field 2030. Thecapability flags field 2030 comprises a T flag 2031, an M flag 2032, anda P flag 2033. The T flag 2031 is about one bit long and indicateswhether the PCE supports initiation of a temporal LSP for a given timeinterval. The M flag 2032 is about one bit long and indicates whetherthe PCE supports path computation for a temporal P2MP LSP in a giventime interval. The P flag 2033 is about one bit long and indicateswhether the PCE supports path computation for a temporal P2P LSP in agiven time interval. The capability flags field 2030 may comprise otherflags as described in the PCEP.

FIG. 21 is a schematic diagram illustrating a stateful PCE capabilityTLV 2100 according to an embodiment of the disclosure. The TLV 2100 isemployed by a PCE such as the PCE-TTS unit 312, 362, and 412 to exchangepath computation capability information with other PCEs when employingthe PCEP. The TLV 2100 is an extension to the stateful PCE capabilityTLV described in the IETF draft documentdraft-ietf-pce-stateful-pce-14.txt. For example, the PCE sends a PCEPopen message comprising the TLV 2100 to another PCE during a PCEPsession establishment, where the PCEP open message is described in theIETF draft document RFC 5440. The TLV 2100 comprises a type field 2110,a length field 2120, and a capability flags field 2130. The type field2110 is about two octets long and is set to a value of sixteen toindicate that the TLV 2100 is a stateful PCE capability TLV. The lengthfield 2120 is about two octets long and indicates a length of thecapability flags field 2130. The capability flags field 2130 comprises aT flag 2131, an M flag 2132, and a P flag 2133. The T flag 2131 is aboutone bit long and indicates whether the PCE supports initiation of atemporal LSP for a given time interval. The M flag 2132 is about one bitlong and indicates whether the PCE supports path computation for atemporal P2MP LSP in a given time interval. The P flag 2133 is about onebit long and indicates whether the PCE supports path computation for atemporal P2P LSP in a given time interval. The capability flags field2130 may comprise other flags as described in the PCEP.

FIG. 22 is a schematic diagram illustrating an RP object 2200 accordingto an embodiment of the disclosure. The RP object 2200 is employed by aPCE such as the PCE-TTS unit 312, 362, or 412 to request other PCEs tocompute paths, reserve resources, or release resources for a temporalLSP such as the LSPs 371 or 471 in predetermined time intervals. Forexample, the RP object 2200 may be included in a PCReq message or aPCRep message. The PCReq and PCRep messages are described in the IETFdraft document draft-ietf-pce-stateful-pce-14.txt. The RP object 2200 isemployed to indicate parameters related to a path computation request, aresource reservation request, or a resource release request. The RPobject 2200 includes a flags field 2210, a request ID Number field 2220,and one or more optional TLVs 2230. The flags field 2210 is about fouroctets long. The flags field 2210 comprises an operation on timeinterval (OTI) flag 2211 and an N flag 2212.

The OTI flag 2211 is about three bits long. For example, the OTI flag2211 is set to a value of one to indicate that a path computationrequest for a particular time interval, a value of two to indicate thata resource reservation request for a particular time interval, or avalue of three to indicate that a resource release request for aparticular time interval. The N flag 2212 is about one bit long. Forexample, the N flag 2212 is set to a value of zero to indicate that therequest is for a P2P LSP or a value of one to indicate that the requestis for a P2MP LSP. Thus, the OTI flag and the N flag 2212 may becombined request path computation, resource reservation, or resourcereleases for a temporal P2P LSP or a temporal P2MP LSP for a particulartime interval. The request ID number field 2220 is about four octetslong and indicates an identifier for the request. The optional TLV 2230is variable in length and may include TLVs related to the request.

FIG. 23 is a schematic diagram illustrating a time-interval object 2300according to an embodiment of the disclosure. The time-interval object2300 is employed by a PCE such as the PCE-TTS unit 312, 362, or 412 toindicate scheduled time intervals for temporal LSPs such as the LSPs 371and 471. The time-interval object 2300 may be included in a PCReqmessage, a PCRep message, a PCInitiate message, or a PCRpt message. ThePCInitiate and PCRpt messages are described in IETF documentdraft-ietf-pce-pce-initiated-lsp-04. The time-interval object 2300 issimilar to a PCEP object as described in the PCEP. The time-intervalobject 2300 comprises an object-class field 2310, an object type (OT)field 2320, a length field 2330, and a time-interval object Body field2340. The object-class field 2310 is about one octet long and indicatesa time-interval object-class. For example, the object-class field 2310may be set to a value of 16 to indicate that the time-interval object2300 is a time interval object. The object-type field 2320 is about oneoctet long and indicates a time-interval object-type. The length field2330 is about two octets long and indicates the length of thetime-interval object body field 2340. The time-interval object bodyfield d 2340 is variable in length and may comprise one or more TLVsassociated with one or more time intervals employed for path computationas described more fully below.

FIG. 24 is a schematic diagram illustrating an absolute time intervalTLV 2400 according to an embodiment of the disclosure. The absolute timeinterval TLV 2400 is employed by a PCE such as the PCE-TTS unit 312,362, and 412 to indicate scheduled time intervals for temporal LSPs suchas the LSPs 371 and 471. The absolute time interval TLV 2400 may beincluded in a time-interval object 2300 of a PCReq message, a PCRepmessage, a PCInitiate message, and a PCRpt message. The absolute timeinterval TLV 2400 comprises a type field 2410, a length field 2420, aStart-time field 2440, and an End-time field 2450. The type field 2410is about two octets long and indicates that the time interval TLV 2400is an absolute time interval TLV. The length field 2420 is about twooctets long and indicates a length of the absolute time interval TLV2400.

The start-time field 2440 is about four octets long and indicates anabsolute time, denoted as Ta, when a LSP is scheduled to start carryingtraffic. The end-time field 2450 is about four octets long and indicatesan absolute time, denoted as Tb, when the LSP is scheduled to stopcarrying traffic. Thus, the scheduled time interval is from Ta to Tb.The absolute time Ta and Tb are clock times that are synchronized amongall nodes such as the edge nodes 121, 321, and 421 and all internalnodes such as the internal nodes 122, 322, and 422 in a network such asthe systems 100, 300, or 400.

FIG. 25 is a schematic diagram illustrating a relative time interval TLV2500 according to an embodiment of the disclosure. The relative timeinterval TLV 2500 is employed by a PCE such as the PCE-TTS unit 312,362, or 412 to indicate scheduled time intervals for temporal LSPs suchas the LSPs 371 or 471. The relative time interval TLV 2500 may beincluded in a time-interval object 2300 of a PCReq message, a PCRepmessage, a PCInitiate message, or a PCRpt message. The relative timeinterval TLV 2500 comprises a type field 2510, a length field 2520, astart-time-length field 2540, and an end-time-length field 2550. Thetype field 2510 is about two octets long and indicates that the timeinterval TLV 2500 is a relative time interval TLV. The length field 2520is about two octets long and indicates a length of the relative timeinterval TLV 2500.

The start-time-length field 2540 is about four octets long and indicatesa time duration in some time units such as seconds from a current localtime to a time that a LSP starts to carry traffic. The end-time-lengthfield 2550 is about four octets long and indicates a time duration insome time units such as seconds from a current local time to a time thatthe LSP stops carrying traffic. For example, the time interval is a timeperiod from a first time, denoted as Ta, to a second time, denoted asTb. Then, the start-time-length field 2540 indicates a start time lengthof Ta—the current local time, and the end-time-length field 2550indicates an end time length of Tb—the current local time.

FIG. 26 is a schematic diagram illustrating a combined time interval TLV2600 according to an embodiment of the disclosure. The combined timeinterval TLV 2600 is employed by a PCE such as the PCE-TTS unit 312,362, or 412 to indicate scheduled time intervals for temporal LSPs suchas the LSPs 371 or 471. The combined time interval TLV 2600 may beincluded in a time-interval object 2300 of a PCReq message, a PCRepmessage, a PCInitiate message, or a PCRpt message. The combined timeinterval TLV 2600 comprises a type field 2610, a length field 2620, astart-time field 2640, and an end-time-length field 2650. The type field2610 is about two octets long and indicates that the time interval TLV2600 is a combined time interval TLV. The length field 2620 is about twooctets long and indicates a length of combined time interval TLV 2600.The start-time field 2640 is similar to the start-time field 2440. Theend-time-length field 2650 is similar to the end-time-length field 2550.

FIG. 27 is a schematic diagram illustrating a recurrent absolute timeinterval TLV 2700 according to an embodiment of the disclosure. Therecurrent absolute time interval TLV 2700 is employed by a PCE such asthe PCE-TTS unit 312, 362, or 412 to indicate scheduled time intervalsfor temporal LSPs such as the LSPs 371 or 471. The recurrent absolutetime interval TLV 2700 may be included in a time-interval object 2300 ofa PCReq message, a PCRep message, a PCInitiate message, or a PCRptmessage. The recurrent absolute time interval TLV 2700 comprises a typefield 2710, a length field 2720, a start-time field 2740, an end-timefield 2750, a repeat-time-length field 2760, an options field 2770, anumber-repeat field 2780, and a millisecond (MS) field 2790. The typefield 2710 is about two octets long and indicates that the time intervalTLV 2700 is a recurrent absolute time interval TLV. The length field2720 is about two octets long and indicates a length of recurrentabsolute time interval TLV 2700. The start-time field 2740 is similar tothe start-time fields 2440 and 2640. The end-time-length field 2750 issimilar to the end-time-length field 2450.

The repeat-time-length field 2760 is about four octets long andindicates a time duration in seconds between the start of each timeinterval at which a LSP is scheduled for carrying to traffic. Theoptions field 2770 is about one octet long and indicates a repeatduration. For example, the options field 2770 may be set to a value ofone to indicate a per day repeat cycle. The options field 2770 may beset to a value of two to indicate a per week repeat cycle. The optionsfield 2770 may be set to a value of three to indicate a per month repeatcycle. The options field 2770 may be set to a value of four to indicatea per year repeat cycle. The options field 2770 may be set to a value offive to indicate a repeat cycle according to the repeat-time-lengthfield 2760. The number-repeats field 2780 is about three octets long andindicates a number of repeats for the scheduled time interval. It shouldbe noted that the repeat-time-length field 2760 is valid when theoptions field 2770 is set to a value of five. The MS field is about oneoctet long and indicates a time extension for extending the durationindicated in the repeat-time-length field 2760 in milliseconds.

FIG. 28 is a schematic diagram illustrating a recurrent combined timeinterval TLV 2800 according to an embodiment of the disclosure. Therecurrent combined time interval TLV 2800 is employed by a PCE such asthe PCE-TTS unit 312, 362, or 412 to indicate scheduled time intervalsfor temporal LSPs such as the LSPs 371 or 471. The recurrent combinedtime interval TLV 2800 may be included in a time-interval object 2300 ofa PCReq message, a PCRep message, a PCInitiate message, or a PCRptmessage. The recurrent combined time interval TLV 2800 comprises a typefield 2810, a length field 2820, a start-time field 2840, anend-time-length field 2850, a repeat-time-length field 2860, an optionsfield 2870, a number-repeat field 2880, and an MS field 2890. The typefield 2810 is about two octets long and indicates that the time intervalTLV 2800 is a recurrent combined time interval TLV. The length field2820 is about two octets long and indicates a length of the recurrentcombined time interval TLV 2800. The start-time field 2840 is similar tothe start-time fields 2440, 2640, and 2740. The end-time-length field2850 is similar to the end-time-length fields 2550 and 2650. Therepeat-time-length field 2860 is similar to the repeat-time-length field2760. The options field 2870 is similar to the options field 2770. Thenumber-repeats field 2880 is similar to the number-repeats field 2780.The MS field 2890 is similar to the MS field 2790.

FIG. 29 is a schematic diagram illustrating a recurrent relative timeinterval TLV 2900 according to an embodiment of the disclosure. Therecurrent relative time interval TLV 2900 is employed by a PCE such asthe PCE-TTS unit 312, 362, or 412 to indicate scheduled time intervalsfor temporal LSPs such as the LSPs 371 or 471. The recurrent relativetime interval TLV 2900 may be included in a time-interval object 2300 ofa PCReq message, a PCRep message, a PCInitiate message, or a PCRptmessage. The recurrent relative time interval TLV 2900 comprises a typefield 2910, a length field 2920, a start-time-length field 2940, anend-time-length field 2950, a repeat-time-length field 2960, an optionsfield 2970, a number-repeat field 2980, and an MS field 2990. The typefield 2910 is about two octets long and indicates that the time intervalTLV 2900 is a recurrent relative time interval TLV. The length field2920 is about two octets long and indicates a length of the recurrentrelative time interval TLV 2900. The start-time-length field 2940 issimilar to the start-time-length fields 2540 and 2640. Theend-time-length field 2950 is similar to the end-time-length fields 2550and 2650. The repeat-time-length field 2960 is similar to therepeat-time-length field 2760. The options field 2970 is similar to theoptions field 2770. The number-repeats field 2980 is similar to thenumber-repeats field 2780. The MS field 2990 is similar to the MS field2790.

In an embodiment of LSP creation, the PCInitiate message comprises astateful request parameters (SRP) object, a LSP object, an end-pointsobject, an explicit route object (ERO) object, and a time intervalobject such as the time-interval object 2300, which may comprise a timeinterval TLV such as the time interval TLVs 2400, 2500, 2600, 2700, or2800. The SRP object, the LSP object, the end-point object, and the EROobject are as described in the IETF draft documents RFC 5440 andietf-pce-pce-initiated-lsp-05.txt. The SRP object comprises aSRP-ID-number. The LSP object comprises a PLSP-ID set of 0 and aSYMBOLIC-PATH-NAME TLV indicating a path name. The end-points objectcomprises the source and the destination addresses of the temporal LSP.The ERO object comprises the path of the temporal LSP.

In such an embodiment, the PCRpt message comprises an SRP object, a LSPobject, an ERO object, and a time interval object such as thetime-interval object 2300, which may comprise a time interval TLV suchas the time interval TLVs 2400, 2500, 2600, 2700, or 2800. The SRPobject comprises the SRP-ID-number in the corresponding PCInitiatemessage. The LSP object comprises a PLSP-ID assigned to the temporal LSPby the PCC, a SYMBOLIC-PATH-NAME TLV indicating a path name, and acreation (C) flag set to a value of one to indicate that the temporalLSP is created by the LSP creation request. The ERO object comprises thepath of the temporal LSP.

In an embodiment of LSP deletion, the PCInitiate message comprises a SRPobject, a LSP object, and a time interval object such as thetime-interval object 2300, which may comprise a time interval TLV suchas the time interval TLVs 2400, 2500, 2600, 2700, or 2800. The SRPobject and the LSP object are as described in the IETF draft documentsRFC 5440 and ietf-pce-pce-initiated-lsp-05.txt. The SRP object comprisesa SRP-ID-number and an R flag set to a value of one to indicate a LSPdeletion request. The LSP object comprises a PLSP-ID (e.g., a global ID)of the temporal LSP.

In such an embodiment, the PCRpt message comprises an SPR object and aLSP object. The SRP object comprises the SRP-ID-number in thecorresponding LSP deletion request. The LSP object comprises a R flagset to a value of one to indicate the temporal LSP is removed from thePCC, and a LSP identifiers TLV.

In an embodiment, an NE includes means for computing a path in a networkfor a temporal LSP, wherein the path satisfies a constraint in a timeinterval comprising a predetermined start time and a predetermined endtime, means for reserving, at a current time prior to the predeterminedstart time via the processor, a first network resource on a link alongthe path computed for the temporal LSP, wherein the first networkresource is reserved for the temporal LSP to carry traffic in the timeinterval, and means for sending, at the predetermined start time via atransmitter of the NE, a LSP creation request to a node associated withthe temporal LSP to request creation of the temporal LSP along the pathin the network.

In another embodiment, an NE includes means for receiving, by a T-LSPmanager of a network controller, a request for creating a temporal LSPin a time interval, means for computing, by a T-PCE of the networkcontroller, a shortest path in a network satisfying a constraint for theLSP in the time interval, means for reserving, in a T-TED of the networkcontroller, resources on each link the LSP traverses for the timeinterval, and means for initiating, at a beginning of the time intervalby the T-LSP manager, setup of the LSP in the network through sending aLSP creation request to a PCC on an ingress node of the LSP.

While several embodiments have been provided in the present disclosure,it should be understood that the disclosed systems and methods might beembodied in many other specific forms without departing from the spiritor scope of the present disclosure. The present examples are to beconsidered as illustrative and not restrictive, and the intention is notto be limited to the details given herein. For example, the variouselements or components may be combined or integrated in another systemor certain features may be omitted, or not implemented.

In addition, techniques, systems, subsystems, and methods described andillustrated in the various embodiments as discrete or separate may becombined or integrated with other systems, modules, techniques, ormethods without departing from the scope of the present disclosure.Other items shown or discussed as coupled or directly coupled orcommunicating with each other may be indirectly coupled or communicatingthrough some interface, device, or intermediate component whetherelectrically, mechanically, or otherwise. Other examples of changes,substitutions, and alterations are ascertainable by one skilled in theart and could be made without departing from the spirit and scopedisclosed herein.

What is claimed:
 1. A method implemented by a network controller in anetwork, comprising: receiving, by a temporal label switched path(T-LSP) manager of the network controller, a request for creating atemporal label switched path (LSP) in a scheduled time interval;computing, by a temporal path computation element (T-PCE) of the networkcontroller, a shortest path in a network satisfying a constraint for thetemporal LSP in the scheduled time interval; reserving, in a temporaltraffic engineering database (T-TED) of the network controller,resources on each link the LSP traverses for the scheduled timeinterval; and initiating, at a beginning of the scheduled time intervalby the T-LSP manager, setup of the LSP in the network through sending aLSP creation request to a path computation client (PCC) on an ingressnode of the LSP.
 2. The method of claim 1, further comprising sending,by the T-PCE, a path computation element (PCE) communication protocol(PCEP) open message indicating that the T-PCE is capable of supportingtemporal LSP path computation, temporal LSP initiation, and temporal LSPmaintenance.
 3. The method of claim 1, wherein the temporal LSP crossesmultiple domains in the network, wherein the method further comprisescommunicating, by the T-PCE, with a remote T-PCE to get an end-to-endpath for the LSP crossing the multiple domains via a path computationelement (PCE) communication protocol (PCEP) path computation request(PCReq) message, and wherein the PCReq message comprises a requestparameter (RP) object comprising an operation on time interval (OT)field indicating whether the PCReq message is a first request for pathcomputation in the scheduled time interval, a second request forbandwidth reservation for the scheduled time interval, or a thirdrequest for bandwidth release for the scheduled time interval, and aN-bit field indicating whether the temporal LSP is a point-to-point(P2P) LSP or a point-to-multipoint (P2MP) LSP.
 4. The method of claim 3,wherein the scheduled time interval is a time period from a first timeTa, to a second time Tb, wherein the PCReq message further comprises atime-interval object comprising: a start-Time field indicating the firsttime Ta that the LSP starts to carry traffic; and an end-Time fieldindicating the second time Tb that the LSP ends carrying the traffic,and wherein the first time Ta and the second time Tb are clock timesthat are synchronized among all network elements (NEs) in the network.5. The method of claim 3, wherein the scheduled time interval is a timeperiod from a first time Ta, to a second time Tb, and wherein the PCReqmessage further comprises a time-interval object comprising: astart-time-length field indicating a start-time length in seconds from acurrent local clock time to the first time Ta that the LSP starts tocarry traffic, wherein the start-time length is Ta minus the currentlocal clock time; and an end-time-length field indicating an end-timelength in seconds from the current local clock time to the second timeTb that the LSP ends carrying the traffic, wherein the end-time lengthis Tb minus the current local clock time.
 6. The method of claim 3,wherein the scheduled time interval is a recurrent time interval thatthe LSP carries traffic, and wherein the PCReq message further comprisesa time interval object comprising: a number-repeats field indicating anumber of repeats; a repeat-time-length field indicating a repeat-timelength in seconds of a repeat cycle for the recurrent time interval; andan options field indicating whether the recurrent time interval repeatsevery day, every week, every month, every year, or repeats everyrepeat-time length.
 7. The method of claim 1, wherein the requestincludes at least one of constraints of the temporal LSP, timinginformation about the scheduled time interval, or traffic informationabout traffic to be forwarded along the temporal LSP.
 8. A networkcontroller implemented in a network, comprising: a receiver configuredto receive a request for creating a temporal label switched path (LSP)in a scheduled time interval; a processor coupled to the receiver andconfigured to: compute a shortest path in a network satisfying aconstraint for the temporal LSP in the scheduled time interval; reserve,in a temporal traffic engineering database (T-TED) of the networkcontroller, resources on each link the LSP traverses for the scheduledtime interval; and initiate, at a beginning of the scheduled timeinterval, setup of the LSP in the network through sending a LSP creationrequest to a path computation client (PCC) on an ingress node of theLSP.
 9. The network controller of claim 8, further comprising atransmitter coupled to the processor and configured to send a pathcomputation element (PCE) communication protocol (PCEP) open messageindicating that the network controller is capable of supporting temporalLSP path computation, temporal LSP initiation, and temporal LSPmaintenance.
 10. The network controller of claim 8, wherein the temporalLSP crosses multiple domains in the network, wherein the networkcontroller further comprises a transmitter coupled to the processor andconfigured to communicate with a remote temporal path computationelement (T-PCE) to get an end-to-end path for the LSP crossing themultiple domains via a path computation element (PCE) communicationprotocol (PCEP) path computation request (PCReq) message, and whereinthe PCReq message comprises a request parameter (RP) object comprisingan operation on time interval (OT) field indicating whether the PCReqmessage is a first request for path computation in the scheduled timeinterval, a second request for bandwidth reservation for the scheduledtime interval, or a third request for bandwidth release for thescheduled time interval, and a N-bit field indicating whether thetemporal LSP is a point-to-point (P2P) LSP or a point-to-multipoint(P2MP) LSP.
 11. The network controller of claim 10, wherein thescheduled time interval is a time period from a first time Ta, to asecond time Tb, wherein the PCReq message further comprises atime-interval object comprising: a start-Time field indicating the firsttime Ta that the LSP starts to carry traffic; and an end-Time fieldindicating the second time Tb that the LSP ends carrying the traffic;wherein the first time Ta and the second time Tb are clock times thatare synchronized among all network elements (NEs) in the network. 12.The network controller of claim 10, wherein the scheduled time intervalis a time period from a first time Ta, to a second time Tb, and whereinthe PCReq message further comprises a time-interval object comprising: astart-time-length field indicating a start-time length in seconds from acurrent local clock time to the first time Ta that the LSP starts tocarry traffic, wherein the start-time length is Ta minus the currentlocal clock time; and an end-time-length field indicating an end-timelength in seconds from the current local clock time to the second timeTb that the LSP ends carrying the traffic, wherein the end-time lengthis Tb minus the current local clock time.
 13. The network controller ofclaim 10, wherein the scheduled time interval is a recurrent timeinterval that the LSP carries traffic, and wherein the PCReq messagefurther comprises a time interval object comprising: a number-repeatsfield indicating a number of repeats; a repeat-time-length fieldindicating a repeat-time length in seconds of a repeat cycle for therecurrent time interval; and an options field indicating whether therecurrent time interval repeats every day, every week, every month,every year, or repeats every repeat-time length.
 14. The networkcontroller of claim 8, wherein the request includes at least one ofconstraints of the temporal LSP, timing information about the scheduledtime interval, or traffic information about traffic to be forwardedalong the temporal LSP.
 15. A network controller, comprising: a memoryconfigured to store instructions; and a processor coupled to the memoryand configured to execute the instructions, which when executed, causethe processor to be configured to: receive a request for creating atemporal label switched path (LSP) in a scheduled time interval; computea shortest path in a network satisfying a constraint for the temporalLSP in the scheduled time interval; reserve, in a temporal trafficengineering database (T-TED) of the network controller, resources oneach link the LSP traverses for the scheduled time interval; andinitiate, at a beginning of the scheduled time interval, setup of theLSP in the network through sending a LSP creation request to a pathcomputation client (PCC) on an ingress node of the LSP.
 16. The networkcontroller of claim 15, wherein the instructions, when executed, furthercause the processor to be configured to send a path computation element(PCE) communication protocol (PCEP) open message indicating that thenetwork controller is capable of supporting temporal LSP pathcomputation, temporal LSP initiation, and temporal LSP maintenance. 17.The network controller of claim 15, wherein the temporal LSP crossesmultiple domains in the network, wherein the instructions, whenexecuted, further cause the processor to be configured to communicatewith a remote temporal path computation element (T-PCE) to get anend-to-end path for the LSP crossing the multiple domains via a pathcomputation element (PCE) communication protocol (PCEP) path computationrequest (PCReq) message, and wherein the PCReq message comprises arequest parameter (RP) object comprising an operation on time interval(OT) field indicating whether the PCReq message is a first request forpath computation in the scheduled time interval, a second request forbandwidth reservation for the scheduled time interval, or a thirdrequest for bandwidth release for the scheduled time interval, and aN-bit field indicating whether the temporal LSP is a point-to-point(P2P) LSP or a point-to-multipoint (P2MP) LSP.
 18. The networkcontroller of claim 16, wherein the scheduled time interval is a timeperiod from a first time Ta, to a second time Tb, wherein the PCReqmessage further comprises a time-interval object comprising: astart-Time field indicating the first time Ta that the LSP starts tocarry traffic; and an end-Time field indicating the second time Tb thatthe LSP ends carrying the traffic; wherein the first time Ta and thesecond time Tb are clock times that are synchronized among all networkelements (NEs) in the network.
 19. The network controller of claim 16,wherein the scheduled time interval is a time period from a first timeTa, to a second time Tb, and wherein the PCReq message further comprisesa time-interval object comprising: a start-time-length field indicatinga start-time length in seconds from a current local clock time to thefirst time Ta that the LSP starts to carry traffic, wherein thestart-time length is Ta minus the current local clock time; and anend-time-length field indicating an end-time length in seconds from thecurrent local clock time to the second time Tb that the LSP endscarrying the traffic, wherein the end-time length is Tb minus thecurrent local clock time.
 20. The network controller of claim 16,wherein the scheduled time interval is a recurrent time interval thatthe LSP carries traffic, and wherein the PCReq message further comprisesa time interval object comprising: a number-repeats field indicating anumber of repeats; a repeat-time-length field indicating a repeat-timelength in seconds of a repeat cycle for the recurrent time interval; andan options field indicating whether the recurrent time interval repeatsevery day, every week, every month, every year, or repeats everyrepeat-time length.
 21. The network controller of claim 16, wherein therequest includes at least one of constraints of the temporal LSP, timinginformation about the scheduled time interval, or traffic informationabout traffic to be forwarded along the temporal LSP.